Naoya vs GoFullPage
GoFullPage is the long-standing, most widely installed extension in this category, and a reasonable default for a lot of people. This page is not an attack on it — it is a specific, honest account of where Naoya’s architecture is different, and where GoFullPage might still be the better fit for you. Every claim below is about Naoya’s own code, not a guess about GoFullPage’s — where we have not looked at its internals, we say so instead of filling the gap with an assumption.
The service worker owns the capture, not the popup
In Naoya, clicking the toolbar icon opens a popup that starts the capture, but the capture itself runs in the extension’s background service worker. Closing the popup does not interrupt the run — there is nothing to interrupt, because the popup was never the thing doing the work. This is an architectural choice we can point to directly in the source: the popup calls into a hub whosegetOrStartCapture either starts a fresh run for that tab or reconnects to one already in flight, and the service worker keeps running that state machine to completion — success or failure — with no dependency on the popup still being mounted to see it through. Reopen the popup while that run is still going and it reconnects to the same in-flight state instead of starting a second one — the guard the function exists for in the first place — so you see the real progress of the run you already started, not a fresh one racing it.
popup closes → service worker keeps going → result tab opens on success
We are not claiming GoFullPage behaves differently here — we have not audited its internals and would rather say nothing than guess. What we can say with confidence is what Naoya does, because it is ours to verify.
Zero network requests, not a privacy policy
Naoya’s capture path makes no network request at all — the packages that scroll, capture and stitch the page contain no networking primitive. That is checkable, not just claimed: a grep forfetch, XMLHttpRequest, sendBeacon, WebSocket and EventSource across the capture, stitcher and exporter packages returns nothing today. See the privacy page for the full data-flow diagram, every hop a capture takes on its way to your disk. If you want a guarantee you can verify rather than a policy you have to trust, that is the difference this page is actually about.
Local history and PDF, without an account
Every capture Naoya produces stays on your device: browsable, re-exportable and deletable, with no sign-up anywhere in the flow. Naoya keeps the 20 most recent captures and evicts the oldest one once a 21st comes in, rather than growing the local store forever — and if the browser’s own storage quota is hit before that eviction catches up, the error names the problem and tells you to open History and free up space, instead of failing silently. Export to PNG, JPEG or a multi-page PDF from the same capture — see that page for how pages taller than the browser’s canvas limit are handled.
Where GoFullPage may still be the better choice
If you need cloud sharing, a link you can send someone, or annotation and editing on top of a capture, Naoya does not do any of that today — on purpose, so capture fidelity gets the attention first. If those features matter more to you than a local-only, verifiably network-free capture, a tool built around them will serve you better than Naoya will right now. We would rather say that plainly than pad this page with a feature comparison we cannot back up with anything we have actually verified in GoFullPage’s own code.
See the fidelity comparator for yourself.