DEV Community: OpenCapture

What permissions a screenshot extension asks for, and what they actually let it do

OpenCapture — Thu, 08 Oct 2026 15:47:01 +0000

“Read and change all your data on all websites” is the scariest sentence in the Chrome Web Store, and most screenshot extensions trigger it. It is worth knowing what it means, because it is avoidable — and an extension that avoided it is telling you something.

The short version. A full-page screenshot tool has to run code inside the page in order to scroll it and measure it. There are two ways to get that ability: activeTab, which grants access to one tab, only when you click the toolbar button, and only until you navigate away; or a broad host permission such as <all_urls>, which grants standing access to every page you ever visit. Both produce a working screenshot tool. Only one of them requires you to trust the developer indefinitely.

The permissions you will see, in plain terms

Permission	What it allows	Scope
`activeTab`	Read and script the current tab	Only after you click the extension, only that tab, only until you navigate
`<all_urls>` / `host_permissions`	Read and script pages	Every matching site, all the time, without any click
`scripting`	Inject the code that does the scrolling and measuring	Only where the extension already has access
`downloads`	Write the finished file to your downloads folder	Files the extension creates
`storage`	Remember your settings	Local to the extension
`tabs`	See the URL and title of every open tab	All tabs, all the time

The two rows that matter are the broad host permission and tabs. Everything else on that list is narrow and boring. Those two are what turn “a tool that photographs a page when I ask it to” into “a program with a standing view of my browsing”.

Why so many screenshot extensions ask for everything

Rarely malice; usually convenience. Building on activeTab means the extension has no access until the user clicks, which rules out anything that wants to act before the click — preloading a content script on every page, watching for navigation, showing a badge that reflects page state. A broad host permission makes all of that trivial, and it is one line in the manifest.

It also makes analytics and monetisation easier later, which is the part worth being alert about. The permission is requested once, at install; what it is used for can change with any update, and updates install silently. Several widely-installed extensions have been sold to new owners and quietly repurposed exactly this way — the users never re-approved anything, because nothing new was asked for.

This is why the permission list matters more than the privacy policy. The policy describes intent today; the permission describes capability for as long as the extension is installed.

How to check a listing before installing

On the store page, open the Privacy practices section and read the permission list, not just the summary sentence.
Look for a broad host permission. “on all sites” or “on every website you visit” is the phrase to notice.
Check whether it asks for tabs. A screenshot tool does not need to know what else is open.
After installing, open the extension’s details page and set site access to On click if the option is available. Most extensions still work.
If the source is public, read the manifest yourself — it is a short file and the permission list is at the top.

What OpenCapture requests

Four permissions, and no broad host permission at all:

activeTab — access to the tab you are on, granted by your click and dropped when you leave.
scripting — to inject the capture routine into that tab.
downloads — to save the finished image or PDF.
storage — to remember your settings.

There is no <all_urls> and no tabs. The only host permissions in the manifest are optional and limited to two OpenCapture domains, requested only if you choose to buy credits for the optional tiled-watermark feature; decline them and the capture, editing and export features are unaffected, because none of them involve a network at all — the stitching and image processing run locally in a Rust/WebAssembly core.

You do not have to take that on trust. The manifest is in the public repository, the extension is AGPL-3.0, and the permission list on the store page is the same four entries.

What the permissions cannot tell you

Being honest about the limits: a narrow permission set constrains what an extension is able to do, but it does not prove what it does with the access it has. activeTab still means that on the tab you clicked, at that moment, the extension can read the page. The guarantees worth looking for are cumulative — narrow permissions, public source, a verifiable build, and no network calls in the capture path. Any one of them alone is weaker than it sounds.

Common questions

Why does a screenshot extension need to read all my data on all websites?

It usually does not. Capturing a full page requires running code in the page, but activeTab grants that for the current tab on click. A broad host permission is a convenience for the developer, not a requirement of the feature.

What does activeTab actually allow?

Reading and scripting the tab you are on, granted when you click the extension and revoked when you navigate away. It gives no access to other tabs and no access before the click.

Can I restrict an extension that already asks for everything?

Yes. On the extension’s details page, set site access to “On click”. Many extensions keep working; the ones that break were relying on background access.

What permissions does OpenCapture request?

activeTab, scripting, downloads and storage — no broad host permission and no tabs permission. Two optional host permissions cover the paid credit purchase only.

Add to Chrome Firefox Edge

Free. No account required. Nothing is uploaded.

Blurring sensitive information in a screenshot — and when it is not enough

OpenCapture — Thu, 08 Oct 2026 15:46:20 +0000

Blur is the default redaction tool everywhere, and for most things it is fine. For short, predictable text — an order number, a six-digit code, an email address on a known domain — it is weaker than almost anyone assumes.

The short version. Blur and pixelation are reversible in principle: the original pixels are averaged, not removed, and short text drawn from a small set of possibilities can often be recovered by trying candidates until one blurs to the same result. For anything that actually matters, cover it with a solid block, and make sure the redaction is applied to the pixels before the file is saved — not as a layer or an overlay that can be peeled off.

The same log before and after. In the exported file the source pixels are gone, not covered.

Two ways a redaction fails

1. The redaction was never in the image

This is the common one and the more embarrassing. Some tools draw the black box as an object in a document, a layer in a file format, or a CSS overlay in a preview. Export or open that file in something else and the box moves, or is simply removed, and the original is underneath. It has happened to law firms, government departments and newspapers, repeatedly.

A blurring is only real if the pixels underneath were destroyed at export time. If you can select, move or delete the box after the fact, you have covered the data, not removed it.

2. The blur was reversible

This one is less obvious. A Gaussian blur is a deterministic averaging of neighbouring pixels. Pixelation is the same idea with bigger blocks. Neither adds information and neither destroys as much as it appears to.

If an attacker knows roughly what the text is — a numeric code, a date, a name from a known list, a URL on a known domain — they can render every candidate in the same font at the same size, apply the same blur, and compare. The match is usually unambiguous. This works because the search space is small, not because the blur was done badly.

The practical rule: blur is fine for things that are merely noisy — other people’s avatars, unrelated rows in a table, a busy sidebar. It is not fine for things that are secret.

What to use for what

Content	Use	Why
API key, session token, password	Solid block	High value, and often short enough to brute-force from a blur
Card number, bank details	Solid block	Fixed format, very small search space
Email address, customer name	Solid block	Usually drawn from a guessable set
Faces of uninvolved people	Blur is acceptable	Goal is de-emphasis, not secrecy
Unrelated content around the point	Blur, or crop	Reducing noise, nothing to protect

Things people forget to blur

The URL. Tokens, session IDs and internal hostnames live there, and the address bar is in every screenshot of a browser window.
Browser tabs. Tab titles leak project names, customer names and what else you were doing.
Notifications. A toast or a system banner that appeared mid-capture.
Autocomplete dropdowns. Opened over the field you were demonstrating.
The window title bar and taskbar. Usernames and machine names.
Reflections and second monitors in photographs of screens.

A quick habit that catches most of these: before sharing, look at the image once from the outside in — edges first, content last. The leaks are almost always at the edges, because that is where you were not looking.

Metadata is part of the file

An exported image can carry more than pixels. Screenshots taken by some tools embed the source URL, the window title, a timestamp or the device name in EXIF or PNG text chunks. If you have blurred the URL from the image but it is still in the metadata, you have not blurred it. Strip metadata on export, or check the file before it goes anywhere public.

A routine that holds up

Capture the page, then blur before saving — not after, and not in a second tool.
Use solid fill for anything secret; reserve blur for de-emphasis.
Sweep the edges: URL bar, tabs, title bar, notifications, taskbar.
Export, then reopen the exported file and confirm the blurring is baked into the pixels and nothing sits under it.
Check the file’s metadata if it is going anywhere public.

How OpenCapture handles it

Blur and solid-block blurring are applied to the pixels in the editor, and the export is flattened — there is no separate layer to remove and nothing underneath to recover. All of it runs locally in a Rust/WebAssembly core, so a screenshot containing customer data is never uploaded anywhere in order to be edited, which matters more than the blurring tool itself if the image is sensitive in the first place.

Common questions

Can blurred text in a screenshot be recovered?

Often, yes, when the text is short and predictable. Blur averages pixels rather than removing them, so candidates can be rendered, blurred the same way and compared until one matches. Use a solid block for anything secret.

Is pixelation safer than blur?

No. Pixelation is the same averaging with larger blocks, and is subject to the same candidate-matching attack.

What is the safest way to hide information in a screenshot?

Cover it with a solid, opaque block, flatten the image on export so nothing sits underneath, and strip the file’s metadata before sharing.

What do people most often forget to blur?

The edges of the image: the URL bar, tab titles, notifications, the taskbar and the window title. Content gets checked; edges do not.

Add to Chrome Firefox Edge

Free. No account required. Nothing is uploaded.

Your browser already takes full-page screenshots. When do you actually need an extension?

OpenCapture — Thu, 08 Oct 2026 15:45:38 +0000

Chrome, Firefox and Edge can all capture a whole scrolling page with no extension installed. Almost nobody knows the Chrome one exists, because it is buried in DevTools. Here is how to use each — and an honest account of where they stop.

The short version. For a one-off PNG of a page, use the browser. It is free, already installed, and there is nothing to trust. An extension earns its place when you need the things the built-in feature does not do at all: annotation, blurring, PDF export, and correct handling of pages long enough to hit the canvas ceiling.

How to do it without installing anything

All three can already do it. Firefox puts it in the right-click menu — Take Screenshot, then Save full page. Edge has Web capture on Ctrl + Shift + S, with a pen and an eraser afterwards. Chrome has no menu entry at all; the command lives in the developer tools.

The step-by-step for each, with screenshots and the gotchas at the save step, is in how to take a scrolling screenshot on desktop.

Where the built-in features stop

	Chrome DevTools	Firefox	Edge Web capture	Dedicated tool
Full-page PNG	Yes	Yes	Yes	Yes
Discoverable	No — DevTools only	Yes	Yes	Yes
Annotation	No	No	Pen only	Yes
Blurring / blur	No	No	No	Yes
PDF export	No	No	No	Yes
Very long pages	Truncates or fails	Warns and caps	Caps	Splits or paginates
Handles lazy images	Partly	Partly	Partly	Waits for them

The last two rows are where the difference is real rather than cosmetic. Every browser caps canvas size — on Chrome, 32,767px on one dimension — and past that limit the built-in capture does not warn you clearly; it hands back an image that is truncated or blank. On a long documentation page or a social feed, that is easy to hit.

The other difference: what happens next

The built-in tools give you a file and stop. That is a feature if all you wanted was the file. It becomes friction the moment the screenshot has a job to do — going into a ticket with an arrow on it, into a document with a customer name covered, into an email as a PDF that keeps the layout.

At that point the built-in route becomes: capture, open an image editor, annotate, blur, export, convert. Three tools instead of one, and the blurring step happens somewhere you have to think about, rather than before the file was ever written.

Worth saying plainly: if you take a screenshot once a month and paste it straight into a chat, the browser’s own feature is the right answer and an extension is overhead.

What to check before installing anything

The cost of an extension is not the download; it is the access. A full-page capture tool has to run code inside the page, and there are two ways to be granted that — narrowly, on click, for one tab, or broadly, for every site you visit, permanently. Most ask for the broad version. Check the permission list on the store page before installing; there is a fuller explanation in the piece on permissions.

Where OpenCapture sits

OpenCapture does the four things the built-in features do not: annotation, solid-block and blur blurring, PDF export, and long pages split or paginated instead of truncated. It asks for activeTab rather than access to every site, and the capture, editing and export all run locally in a Rust/WebAssembly core, so nothing about the page is uploaded. It is free and open source; the only paid element is an optional tiled-watermark feature ($5 for 1,000 credits, once).

If none of those four things are what you need, use DevTools. That advice costs us an install and it is still the right advice.

Common questions

How do I take a full-page screenshot in Chrome without an extension?

Open DevTools, press Ctrl+Shift+P, type screenshot and choose Capture full size screenshot.

How do I take a full-page screenshot in Firefox?

Right-click the page, choose Take Screenshot, then Save full page. The Firefox guide has the screenshots and the three limits of that tool.

Why did Chrome’s built-in full-page screenshot come out blank or cut off?

The page exceeded the browser’s canvas limit — 32,767px on one dimension on Chrome. Past that, drawing silently fails. Tools built for long pages split the output into segments instead.

Do I need a screenshot extension at all?

Only if you need annotation, blurring, PDF export, or pages long enough to break the built-in capture. For a one-off PNG, the browser’s own feature is enough.

Add to Chrome Firefox Edge

Free. No account required. Nothing is uploaded.

How full-page screenshots actually work — and the four ways they break

OpenCapture — Thu, 08 Oct 2026 15:44:46 +0000

A browser can only ever photograph the part of a page currently on screen. Every “full page” screenshot is therefore several photographs glued together — and almost all of the interesting bugs live in the glue.

The short version. Capture scrolls the page, photographs each viewport, and stitches the slices onto one canvas. Four things go wrong: sticky headers repeat in every slice, lazy images get photographed before they load, inner scroll regions are never scrolled at all, and device-pixel rounding leaves hairlines at every seam. There is a one-minute test further down that catches all four.

The loop, and exactly where it breaks

Strip away the details and every implementation is the same four steps, repeated until you reach the bottom of the document:

Scroll to the next vertical offset.
Photograph whatever is currently visible — that is one slice.
Advance the offset by one viewport height.
Draw every slice onto a single canvas, in order, and export it.

Write that and you will have something working in an afternoon. Point it at a real website and it falls apart within about thirty seconds, in four distinct ways. Each has a recognisable symptom, so once you know them you can tell at a glance which one you are looking at.

1. The navigation bar appears six times

An element with position: sticky or position: fixed stays glued to the viewport, which means it is present in every slice. Stitch them and the header marches down the finished image like a flipbook, with the real content sliced up between the repetitions.

The fix is to hide those elements for the duration of the capture and restore them afterwards. It sounds obvious; a surprising number of tools skip it. The same applies to cookie banners, chat bubbles, newsletter popups and back-to-top buttons.

Hiding everything with position: fixed is too blunt. A sticky header is genuinely part of the page and should appear once, at the top, where it belongs.

2. Half the images are grey boxes

Images that load when they enter the viewport need a moment to arrive. Scroll, capture and scroll again with no pause and you photograph the placeholder instead of the picture.

This is the most common cause of a screenshot that looks obviously wrong to a human but is hard to describe. The page looked fine while you were reading it, because you scrolled at human speed and everything had time to load.

A correct implementation scrolls, waits for the network and layout to settle, and only then captures. That is slower — which is exactly why not everything does it.

3. The table only shows four rows

A page can contain its own scrolling regions: a data table with a fixed height, a code block, a chat panel, a sidebar with overflow: auto. Those are separate scroll contexts. A full-page capture scrolls the document; it does not scroll them.

So the outer page comes out complete while the inner region shows only whatever happened to be visible. There is no universal fix — a tool has to detect scrollable descendants and decide what to do about each one, and very few do. Worth knowing so you can spot it rather than assume the capture is complete.

4. Thin lines of duplicated pixels at every seam

This one produces the strangest artefacts. On a HiDPI display the browser renders at 2× or 3×. Scroll offsets are expressed in CSS pixels; the captured bitmap is in device pixels. Mix the two anywhere in the arithmetic and every slice lands a fraction off.

The result is a hairline of duplicated or missing pixels at each boundary. You usually notice it first as text that looks subtly wrong — a line of type carrying a sliver of the line above it. Zoom to 400% at a boundary and it is unmistakable.

The arithmetic that matters: a slice’s destination has to be computed as round(index × viewportHeight × devicePixelRatio), in device pixels. Using the CSS-pixel height directly is what puts the hairlines there.

A fifth problem, on very long pages only

Browsers cap how large a single canvas surface can be. On Chrome that is 32,767px on any one dimension, with a total area ceiling of 268,435,456px. Exceeding either does not raise an error — the canvas silently becomes unusable and draw calls turn into no-ops, so you get a blank or truncated image with nothing in the console to explain it.

Anything that captures genuinely long pages therefore has to split the output into segments rather than allocating one enormous surface. In practice that means a very tall capture arrives as several PNGs, or as a multi-page PDF.

A one-minute test for any tool

Find a page with a sticky header, lazy images, an inner scroll region and roughly 8,000 pixels of height — most documentation sites qualify. Capture it, then check four things:

Check	What a failure looks like	Cause
Header count	The nav bar appears more than once	Sticky elements not hidden
Images below the fold	Grey placeholder boxes	No wait for lazy loading
Inner regions	A table showing only the rows that were on screen	Nested scroll context
Seams at 400% zoom	Thin repeated or missing lines	CSS vs device pixel rounding

A tool that survives that will survive your actual work.

Where the browser’s built-in feature sits

Both Chrome and Firefox can already do this without an extension. In Chrome, open DevTools, press Ctrl+Shift+P, type screenshot and choose Capture full size screenshot. In Firefox, right-click the page and choose Take Screenshot → Save full page.

It gives you a PNG and nothing else — no annotation, no blurring, no PDF — and it is not especially careful about the failure modes above. For a lot of people that is genuinely enough, and it is worth knowing before you install anything.

How OpenCapture handles each of these

OpenCapture hides sticky and fixed elements for the duration of the capture and restores them afterwards, waits for lazy content to settle before each slice, and computes every slice offset in device pixels so seams stay pixel-exact across device pixel ratios. Captures longer than the canvas ceiling are split automatically into multiple images, or paginated into a PDF. Stitching and all image processing run locally in a Rust/WebAssembly core — nothing about the page is uploaded anywhere.

Nested scroll containers remain the one case no tool solves universally. The section above tells you how to spot it.

Common questions

Why does my screenshot show the navigation bar several times?

The tool captured each viewport without hiding elements that use position: sticky or position: fixed, so the header appears in every slice and repeats down the stitched image.

Why are images below the fold grey boxes?

Lazy-loaded images had not finished arriving when the slice was captured. A tool that waits for the network and layout to settle before each capture avoids this.

What are the thin lines running across my stitched screenshot?

Seam artefacts caused by mixing CSS pixels with device pixels when computing scroll offsets. They are most visible on HiDPI displays, where the browser renders at 2× or 3×.

Why did a very long page come back as several images?

Browsers cap the size of a single canvas — on Chrome, 32,767px on one dimension and 268,435,456px of total area. Past that the canvas silently stops working, so long captures are split into segments or paginated into a PDF.

Add to Chrome Firefox Edge

Free. No account required. Nothing is uploaded.

Eight things in your frontend that make your app impossible to screenshot

OpenCapture — Fri, 04 Sep 2026 07:58:50 +0000

Someone eventually tries to capture your app. A user filing a bug, a support agent writing a ticket, a PM building a deck, a customer archiving an invoice. They press whatever full-page screenshot tool they have, and they get something wrong: a nav bar repeated nine times, a table with six rows in it, a page that is mostly grey boxes.

They will not file that as a bug against you. They will just send the broken image, and whoever receives it will misunderstand the problem.

Full-page capture works by scrolling the document, photographing the viewport at each step, and stitching the slices together. Almost everything below is a case where that loop sees something different from what a human sees.

1. `position: fixed` and `position: sticky`

A fixed header is present in every slice, so it appears once per viewport height in the stitched image. Sticky is the same story with extra edge cases at its stuck/unstuck boundary.

Good capture tools detach these for the duration and put them back. Not all of them do, and none of them can guess which of your elements is decorative chrome and which is content.

2. Virtualized lists

This is the one that cannot be worked around from outside.

If you render 20 of 10,000 rows and swap them as the user scrolls - react-window, TanStack Virtual, ag-grid, your own implementation - then rows 21 through 10,000 do not exist in the DOM at any moment. There is no scroll position at which they can be photographed. A capture of your table is a capture of whatever was mounted.

Nothing on the tool side fixes this. The page has to offer a non-virtualized rendering path.

// something a capture tool or a user can actually reach
if (location.search.includes('render=full')) {
  virtualizer.setOptions({ overscan: rows.length })
}

Even a "print view" that renders everything is enough.

3. Lazy-loaded images

IntersectionObserver fires when the image enters the viewport, then the image has to arrive over the network and lay out. A capture loop that scrolls and photographs immediately wins that race and records the placeholder.

The tool should wait. Many don't, and some can't tell the difference between "still loading" and "intentionally blank".

Native loading="lazy" behaves better here than a hand-rolled observer, because browsers already pre-load nearby images and print paths know about it.

4. Inner scroll containers

A capture scrolls the document. A div with overflow: auto is a separate scroll context, and it is not the document.

So the page around it captures fully, and the panel inside it captures whatever slice happened to be visible. Code blocks with max-height, chat panes, data tables with a frozen header, sidebars - all of them silently truncate.

If a region is content rather than a viewport-sized widget, consider letting it grow and letting the page scroll instead.

5. `100vh` app shells

.app  { height: 100vh; display: grid; grid-template-rows: auto 1fr }
.main { overflow-y: auto }

This is a completely normal layout, and it means your document never scrolls. From the outside, your entire application is one viewport tall. A full-page capture of it returns one screen - correctly, because that is the whole document.

Everything real is inside .main, which is case 4.

I ran into this building a demo page for a capture tool: the page had a sticky sidebar and a viewport-height shell, and captures of it kept coming out with a 1,400px empty column. The page was fine. The layout was just not a document.

6. `scroll-behavior: smooth`

Set globally, it turns every programmatic scrollTo into an animation. A capture loop that scrolls and immediately photographs gets a frame from the middle of the animation, and every slice lands at the wrong offset.

Scope it to user-initiated navigation rather than applying it to html unconditionally, or respect the reduced-motion query, which most capture paths and many users share:

@media (prefers-reduced-motion: no-preference) {
  html { scroll-behavior: smooth }
}

7. Scroll-triggered animation

Fade-in-on-scroll means an element's opacity depends on when it was observed. During a fast programmatic scroll, some elements are caught mid-transition and some never trigger at all. The stitched image gets a page with randomly half-faded sections.

Same reduced-motion escape hatch applies.

8. Canvas and WebGL

A WebGL context created without preserveDrawingBuffer: true may be cleared before anything outside the render loop can read it, so it can come back blank or stale depending on the capture path. If a chart matters to your users, it is worth checking what it looks like in a capture rather than assuming.

A test that takes one minute

Open your own app. Use the built-in browser feature - no extension needed:

Chrome: DevTools, Ctrl+Shift+P, type screenshot, choose Capture full size screenshot
Firefox: right-click the page, Take Screenshot -> Save full page

Then check four things:

Check	Failure looks like
Header count	Nav bar appears more than once
Image content	Grey placeholders below the fold
Long lists	A table with only the visible rows
Page height	The capture is exactly one screen tall

If the last row is true, you have case 5 and everything else is moot.

Why bother

Screenshots of your product are how it gets described to people who have not used it - in bug reports, in internal decks, in support threads, in a review someone posts. If those images are broken, the description is broken, and you are not in the room to correct it.

Fixing this is mostly not new code. It is a print/export path, one query parameter that disables virtualization, and not putting scroll-behavior: smooth on html.

Written while working on OpenCapture, a free and open-source (AGPL-3.0) full-page screenshot extension for Chrome, Firefox and Edge. Source is on GitHub if you want to see how any of the above is handled in practice.

Better bug reports: what to screenshot, and what to hide first

OpenCapture — Thu, 03 Sep 2026 06:17:42 +0000

Most bug reports contain a screenshot. Most of those screenshots are either not enough to reproduce the problem, or contain something that should not have left the building.

Both are fixable in about thirty seconds each.

Capture more than the error

The instinct is to screenshot the error message. The error message is usually the least informative part of the page.

What the person fixing it needs is context: the URL, the state of the form, what else was on screen, and — often decisive — the browser console. An error alone tells them what broke. The surrounding page tells them why.

A full-page capture costs nothing extra and removes an entire round trip of "can you send the whole page?"

Include the things you are tempted to crop

The URL bar. Query parameters and path segments are frequently the difference between reproducing a bug and not.

Timestamps. If the page shows one, it lets someone match your report against server logs.

The console. Open DevTools before capturing. A stack trace in the image saves a day.

Your viewport size. Many layout bugs only exist at certain widths. Some tools stamp dimensions on the capture; if not, mention it.

Then hide the things you are tempted to leave

Bug reports travel further than the person writing them expects. They get pasted into group chats, forwarded to vendors, attached to public issue trackers.

Before sending, redact:

Customer names and email addresses visible in tables or headers
Account and order identifiers that map to a real person
API keys or tokens visible in a logged request or a URL
Internal hostnames that reveal infrastructure
Anything in an adjacent browser tab — tab titles are readable

Redaction has a failure mode

Two operations are both called blur, and only one of them removes information.

Some tools draw a blurred overlay while the original pixels remain in the underlying data. Depending on the export, that can sometimes be recovered. Others resample the region and discard the source, which cannot be undone.

Test yours once: blur a line of text, export, open the export, and push contrast and sharpness hard. If characters start resolving, use a solid box instead of blur for anything that matters.

Solid boxes are ugly and completely reliable. For a token, take the ugly option.

A checklist worth pinning

Full page, not just the error
Console open if it is a JavaScript bug
URL visible
Redact names, emails, IDs, tokens, internal hostnames
Check no other tab is readable
Note the browser and viewport width

Six items, about a minute, and it removes most of the back-and-forth that makes bug reports slow.

Disclosure

I work on OpenCapture, an open-source screenshot extension built around this workflow — full page capture, annotation, and a destructive mosaic blur rather than a cosmetic one. But the checklist above works with whatever you already have, including the capture tool already built into your browser.

DEV Community: OpenCapture

What permissions a screenshot extension asks for, and what they actually let it do

The permissions you will see, in plain terms

Why so many screenshot extensions ask for everything

How to check a listing before installing

What OpenCapture requests

What the permissions cannot tell you

Common questions

Why does a screenshot extension need to read all my data on all websites?

What does activeTab actually allow?

Can I restrict an extension that already asks for everything?

What permissions does OpenCapture request?

Blurring sensitive information in a screenshot — and when it is not enough

Two ways a redaction fails

1. The redaction was never in the image

2. The blur was reversible

What to use for what

Things people forget to blur

Metadata is part of the file

A routine that holds up

How OpenCapture handles it

Common questions

Can blurred text in a screenshot be recovered?

Is pixelation safer than blur?

What is the safest way to hide information in a screenshot?

What do people most often forget to blur?

Your browser already takes full-page screenshots. When do you actually need an extension?

How to do it without installing anything

Where the built-in features stop

The other difference: what happens next

What to check before installing anything

Where OpenCapture sits

Common questions

How do I take a full-page screenshot in Chrome without an extension?

How do I take a full-page screenshot in Firefox?

Why did Chrome’s built-in full-page screenshot come out blank or cut off?

Do I need a screenshot extension at all?

How full-page screenshots actually work — and the four ways they break

The loop, and exactly where it breaks

1. The navigation bar appears six times

2. Half the images are grey boxes

3. The table only shows four rows

4. Thin lines of duplicated pixels at every seam

A fifth problem, on very long pages only

A one-minute test for any tool

Where the browser’s built-in feature sits

How OpenCapture handles each of these

Common questions

Why does my screenshot show the navigation bar several times?

Why are images below the fold grey boxes?

What are the thin lines running across my stitched screenshot?

Why did a very long page come back as several images?

Eight things in your frontend that make your app impossible to screenshot

1. position: fixed and position: sticky

2. Virtualized lists

3. Lazy-loaded images

4. Inner scroll containers

5. 100vh app shells

6. scroll-behavior: smooth

7. Scroll-triggered animation

8. Canvas and WebGL

A test that takes one minute

Why bother

Better bug reports: what to screenshot, and what to hide first

Capture more than the error

Include the things you are tempted to crop

Then hide the things you are tempted to leave

Redaction has a failure mode

A checklist worth pinning

Disclosure

1. `position: fixed` and `position: sticky`

5. `100vh` app shells

6. `scroll-behavior: smooth`