SVG Screenshots: browser captures that stay selectable, scalable and readable by a screen reader

What the extension captures is the DOM, not the screen

A normal screenshot is a raster image of pixels. SVG Screenshots produces something structurally different: an SVG document built from the page itself, with text as text and links as links. The project describes it as a browser extension to take semantic, scalable, accessible screenshots of websites in SVG format, as simple as taking a PNG screenshot.

The consequences follow from that mechanism. Text can still be selected and copied to the clipboard, because it is text in the SVG rather than shapes drawn in pixels. Links remain clickable. Zooming does not pixelate, since the output is resolution independent. The SVG is annotated with ARIA attributes so it can be read by a screen reader, which is the part that makes it more than a nicer image format.

Two further properties come from recording the live page. Styles and layout are frozen at the moment of the snapshot and will not change afterwards, so the file behaves like a static document rather than a re-render of a live site. External resources such as images and fonts are inlined, which makes the file self-contained. And the project states that the SVG will not run any JavaScript, so opening one does not execute anything.

The target user is therefore broader than a designer. A documentation author who wants selectable code samples, a designer who wants a vector asset they can open in Illustrator, Figma or Sketch, and an accessibility reviewer who needs a capture a screen reader can narrate are all cases the format addresses.

A selection region or the whole page, and what the output keeps

The capture controls are simple. You can freely select the region of the website you want to capture, or capture the whole page. That is the same choice a user has with a system screenshot tool, and it is what makes the extension usable for a single component rather than only for full-page archives.

The interesting part is what survives into the file. Text remains selectable, so a screenshot of documentation can be pasted into a document with the words still copyable. Links stay interactive, meaning an SVG of a page can be opened and its links followed. The output is annotated with ARIA attributes so assistive technology can read it, which is the concrete accessibility difference between this file and a PNG of the same pixels.

The file also carries its dependencies. Images and fonts are inlined, so the SVG is self-contained and can be handed to someone else without the original site. Because styles and layout are recorded at the time of the snapshot, the rendering does not drift when the source site is later redesigned, which is what makes these files usable as long-lived documentation assets.

Size is the last claim, and it is a qualified one. The project states that depending on the content, SVGs can be magnitudes smaller than PNGs and compress losslessly. The qualification matters. A page that is mostly photography or canvas rendering has little vector structure to exploit, so the size advantage applies to text-and-layout pages rather than to every capture.

Building from source with Parcel, web-ext and semantic-release

There is no install command in the documentation, because there is nothing to install for end users. The project points to the official extension stores, one listing for Chrome and one for Firefox, and those are the supported routes.

For contributors, the repository is a Node project. The package manifest pins Node `^15.2.0` and npm `^7.0.8`, and the scripts cover the whole cycle. The build uses Parcel against the extension manifest:

"build": "parcel build manifest.json --no-minify --no-source-maps",
"watch": "parcel watch manifest.json --no-hmr --no-source-maps"

Firefox builds and runs go through the web-ext tool, which reads the `webExt` section of the manifest:

"firefox:start": "web-ext run",
"firefox:build": "web-ext build --overwrite-dest",
"firefox:watch": "web-ext build --as-needed --overwrite-dest"

Lint and type checks are separate scripts, and a Husky hook installs itself on prepare:

"typecheck": "tsc -p .",
"prepare": "husky install"

Releases are handled by semantic-release, with dedicated plugins for the Chrome and Firefox channels, and commitlint with the conventional config enforces the commit format that semantic-release reads. The browserslist field targets the last three Chrome versions and the last three Firefox versions.

Where the dependency chain and the licensing leave you exposed

The architecture is a thin wrapper over a library called dom-to-svg, and that dependency is where the risk sits. The manifest pins `dom-to-svg` at `^0.12.0`, and the caret range means the extension tracks patch and minor releases of that package within the same major. The rest of the runtime dependencies are small and single purpose: `svgo` for optimising the SVG output, `file-saver` for triggering the download, `xml-formatter` for readable output, `pretty-bytes` for reporting the size, `delay` for sequencing, and `webextension-polyfill` so the same code runs in Chrome and Firefox.

The build toolchain is older than the browsers it targets. Parcel sits at `^1.12.5`, TypeScript at `^4.2.4`, ESLint at `^7.27.0`, and the Node engine range is `^15.2.0`. None of that is a problem for a user installing from a store, but it is a problem for a contributor on a current Node release.

Licensing is where the record is weakest. The repository licence field is listed as unknown, while the project page shows an MIT badge that points at the dom-to-svg repository rather than at svg-screenshots itself. If you intend to fork, vendor or redistribute the code, verify which licence actually applies to this repository before you rely on it. Nothing here is legal advice, but an unknown licence status is a fact worth knowing before adoption rather than after.

The release history has a similar gap. The published versions in the repository are v0.11.5 dated 2021-05-24, v0.11.4 dated 2021-05-23 and v0.11.3 dated 2021-05-23, yet the last push was on 2026-10-13. The source has moved on since those tags, and there is no tag in that recent history to match.

SVG Screenshots next to a system screenshot and next to a vector export

The obvious comparison is the operating system screenshot, and the difference is what the file can still do afterwards. A PNG is a finished picture: text in it cannot be selected, links in it cannot be followed, and a screen reader can only report that an image exists. The SVG version of the same page can be read aloud, searched, clicked and zoomed into. If your use case is a bug report about a layout, a documentation figure, or an accessibility review, that difference decides the tool.

The other comparison is with a vector design export. A tool that saves a page as SVG from a design application produces artwork built for editing, with each shape chosen by a human. This extension produces a faithful transcription of what the browser actually rendered, layout included, which is a different goal. The tradeoff is that a DOM-derived SVG carries the page's own complexity, so an Illustrator file is not what you get, and the recorded layout does not reflect how the page would behave at another viewport size.

There is also the case of doing nothing and cropping a PNG. That is faster for a quick message to a colleague, and it produces a smaller commitment. The extension earns its place only when the capture has to remain editable, readable or long-lived.

MIT badge, semantic-release pipeline and a long gap between tags

Maintenance for a user means trusting the store listing rather than the repository history. The repository is not archived and the last push was on 2026-10-13, so the source is being worked on. The published tags, however, are from May 2021, which means the version a store serves and the current state of the source may not correspond.

The release machinery is the interesting part of the setup. semantic-release with the conventional commit config derives the version from commit messages, and separate plugins for Chrome and Firefox publish the package to each channel. That setup removes version bumps from contributor work, and it means a maintainer who follows the convention can publish without editing a version file. The downside is the same one the repository shows: automated releases depend on maintainer credentials for both stores, and a failure there produces a gap in the tag history rather than an obvious error in the source.

The project also carries a Renovate configuration and a Husky setup with lint-staged-style commit hooks, so dependency updates arrive as automated pull requests. For an extension whose whole value is that it renders the live DOM correctly, a stale dependency on dom-to-svg is the risk to watch, since that library does the actual conversion.

Editorial conclusion

SVG Screenshots fits documentation writers, designers and accessibility testers who need a capture that survives zooming, that can be edited in a vector tool, or that a screen reader can still read. It does not fit anyone who needs a pixel-exact rendering of a canvas-heavy page, since the approach captures DOM structure rather than a rasterised frame, and it does not fit projects that need a supported dependency chain. Before adopting it, check the extension listing for the browser version you run, and look at the examples in the `examples/` directory to see whether the fidelity of your typical target page holds up.

Frequently asked questions

Official sources

1. felixfbecker/svg-screenshots on GitHub
2. Issues
3. README
4. Releases