Obsidian Web Clipper: how pages become portable Markdown across four browsers

Four store listings cover the browsers you actually use

The extension reaches you through four separate listings rather than one download. Chrome Web Store covers Chrome, Brave, Arc, Orion, and the rest of the Chromium family. Firefox Add-Ons serves Firefox and Firefox Mobile. Safari Extensions covers macOS, iOS, and iPadOS. Edge Add-Ons carries the Edge build. All four publish the same Web Clipper, so the choice is really about which browser you keep in front of you. After you add it, the first thing to learn is the capture flow: the help site walks through highlighting, templates, variables, and filters, and what you save lands as a durable Markdown file you can read offline and keep for the long term. Pick the listing that matches your browser and the rest is the same.

https://chromewebstore.google.com/detail/obsidian-web-clipper/cnjifjpddelmedmihgijeibhnjfabmlf
https://addons.mozilla.org/en-US/firefox/addon/web-clipper-obsidian/
https://apps.apple.com/us/app/obsidian-web-clipper/id6720708363
https://microsoftedge.microsoft.com/addons/detail/obsidian-web-clipper/eigdjhmgnaaeaonimdklocfekkaanfme

One build command emits three browser bundles

Developers do not build four separate extensions. A single command runs the Chromium, Firefox, and Safari builds in sequence, and it leaves three directories on disk: `dist/` for the Chromium version, `dist_firefox/` for the Firefox version, and `dist_safari/` for the Safari version. Each `build:*` script is a webpack invocation with a BROWSER environment value and a production mode flag, which is why the per-browser targets exist as separate scripts that the umbrella `build` script chains together. The default `dev` shortcut only watches Chrome. So the same TypeScript source, the same `providers.json`, and the same templates compile three times with different browser targets rather than maintaining parallel codebases. Because the bundles differ only at the packaging edge, a bug in capture logic surfaces on all three targets at once.

npm run build

For Chromium, loading it locally is a short detour into the browser's extension page: open `chrome://extensions`, turn on Developer mode, and use Load unpacked to point at `dist`.

Permanent Firefox installs need signature checks disabled

Loading the freshly built Firefox bundle by hand is easy, because Firefox accepts a temporary add-on straight from disk. Making it permanent is the friction point. The documented route asks you to run a Nightly or Developer build of Firefox, then open the internal preferences editor and set `xpinstall.signatures.required` to `false`. Once that preference is off, you install the packaged add-on file from the add-ons manager. That is a deliberate detour, and it means a release-channel Firefox user cannot follow the same steps to keep a locally built Web Clipper loaded across restarts. The temporary add-on path is the one to use day to day while you are iterating on the code. Turn the preference back on when you are done, because leaving signature enforcement disabled weakens the browser's add-on trust model.

about:config
xpinstall.signatures.required

iOS builds run through Xcode and a simulator

Safari on Apple platforms has its own testing path, and it does not go through the Chrome or Firefox unpacked flow. To test on iOS you build the extension, open the Xcode project at `xcode/Obsidian Web Clipper/Obsidian Web Clipper.xcodeproj`, select the Obsidian Web Clipper (iOS) scheme, choose an iOS Simulator device, and run it. Once the app is up on the simulator, you open Safari, navigate to a page, and tap the Extensions button in the Safari toolbar to reach the clipper. This tells you something about the surface area: a single web extension ships to desktop, mobile, and three browser engines, and each one has its own verification gate. The Xcode project is committed to the repository, which is why the `xcode/` folder shows up in the top level next to `src/` and `scripts/`.

npm run build
xcode/Obsidian Web Clipper/Obsidian Web Clipper.xcodeproj

defuddle pulls the page apart, lz-string shrinks the templates

The capture quality leans on a small set of dependencies with narrow jobs. `defuddle` handles content extraction and the conversion to Markdown, which is the part that decides whether you get a clean article or a wall of navigation markup. `dompurify` sanitizes HTML. `dayjs` handles date parsing and formatting for the variables that templates can insert. `lz-string` compresses templates specifically to reduce storage space, so a large template library does not eat your local quota. `webextension-polyfill` smooths over browser compatibility differences between Chromium and Firefox. `lucide` supplies the icons.

Three roadmap items are still unchecked

The project keeps a public checklist, and the unchecked boxes tell you exactly which conveniences are not there yet. Annotate highlights, a template directory, and syncing settings across browsers are all still planned. The completed items show what shipped in the past: a separate icon for the clipper arrived in 1.6.3, template validation and template logic with if and for arrived in 1.1.0, saving images locally rode along with Obsidian 1.8.0, and the interface has been translated into more languages. The three most recent releases, 1.7.1 on 2026-07-22, 1.7.0 on 2026-06-16, and 1.6.3 on 2026-05-26, show the pace, and the last push is dated 2026-09-22. If you rely on moving a template set from a Mac to a PC, or on annotating a highlight before saving it, neither capability exists in 1.7.1 yet.

A CLI binary and an api export sit in package.json

Underneath the browser extension there is a command line entry point and a separate API export, both declared in the package manifest. The `bin` field maps a command named `obsidian-clipper` to `./dist/cli.cjs`, and the `exports` field points the package root at that same CLI file while a `./api` subpath resolves to `./dist/api.mjs`. The published file list is only `dist`, and the `prepublishOnly` hook builds the CLI and the API before anything is released. This means the parsing and conversion work that powers the extension is packaged so other tools can call it, rather than being locked inside the browser. It also adds a maintenance edge: the CLI and API are built by separate scripts, so an extension-only change can leave those entry points untouched until someone rebuilds them. The source is MIT licensed, with trademarks, icons, marketing copy, and other marketing assets excluded from that license.

Editorial conclusion

Obsidian Web Clipper suits anyone who reads in Obsidian and wants pages turned into portable Markdown they own, across Chrome, Firefox, Safari, or Edge. It is a poor fit if you need cross-browser settings sync, highlight annotation, or a template directory, since all three remain on the roadmap, or if you would rather not disable Firefox signature checks to test a local build. The source is MIT licensed apart from trademarks and marketing assets, the last push is dated 2026-09-22, and the recent releases are steady. Before you commit, decide which browser listing you will use and read the template and filter documentation first.

Frequently asked questions

Official sources

1. License: MIT
2. obsidianmd/obsidian-clipper on GitHub
3. Project website
4. README
5. Releases