Chrome Extension vs Bookmarklet: Which to Build (2026)

A bookmarklet is a bookmark whose address is JavaScript instead of a web address. Click it, and the code runs against whatever page you are looking at. No install, no store, no permissions dialog, no review. For twenty years it has been the fastest way to turn a five-line script into a reusable browser tool.

The Chrome extension vs bookmarklet question comes up whenever someone has a small piece of page automation and has to decide how to package it. The honest answer in 2026 is that bookmarklets have narrowed considerably — not because Chrome removed them, but because the modern web changed around them. Content Security Policy headers block them on a large share of major sites. Chrome has no hotkey binding for them. They cannot touch internal browser pages. Meanwhile Manifest V3 made extensions more constrained but also more predictable.

This is the practical comparison: what each one can do, where each one silently fails, what it costs to ship, and how to decide between them for a specific tool.

What a Bookmarklet Actually Is

A bookmark with a javascript: scheme in the URL field. Chrome stores it exactly like any other bookmark, syncs it across your devices with the rest of your bookmarks, and executes the code in the context of the current page when clicked.

A minimal example that copies the current address:

javascript:navigator.clipboard.writeText(location.href)

That is the entire deployment. Create a new bookmark, paste that into the URL field, name it, put it on the bookmarks bar. It now runs on any page where the click reaches it.

The properties that follow from this design:

• It runs in the page context. Same JavaScript world as the site scripts. It can read and modify the DOM, call page functions, and read anything the page can read.
• It has no persistent state of its own. No storage, no background process, no lifecycle. It fires, it finishes, it is gone.
• It has exactly the privileges of the page. No more, no less. Cross-origin fetches are subject to the same CORS rules the page faces.
• It is one line of readable text. Anyone can inspect it before using it, which is a genuine trust advantage.
• It works in every browser that supports bookmarks, which is all of them. The same string works in Firefox, Safari, and Edge with no changes.

That portability is the strongest argument in the Chrome extension vs bookmarklet comparison. One line of code, five browsers, zero build step.

What a Chrome Extension Actually Is

A packaged bundle — a manifest file plus scripts, and optionally HTML pages, icons, and assets — installed into the browser with a declared set of permissions.

Under Manifest V3, the shape is:

• A service worker for background logic. Event-driven, terminated when idle, restarted when needed.
• Content scripts that Chrome injects into matching pages, running in an isolated world separate from the page scripts.
• Extension APIs the page has no access to: tabs, storage, commands, context menus, alarms, declarativeNetRequest, DevTools panels, side panel, and more.
• A permission model that is declared up front, shown to the user at install, and enforced by the browser.
• No remotely hosted code. Everything that executes must be in the package. This is the headline Manifest V3 restriction and it is why some older extensions died.

In the Chrome extension vs bookmarklet trade, this is the side that costs more up front: a manifest to write, a package to build, a developer account, a store review, and an update pipeline. The benefit is capability. An extension can bind a keystroke, hold state between sessions, act on tabs it is not currently displaying, add a context menu item, and keep working on pages that block inline script entirely.

For the build mechanics, see how to build a Chrome extension, which walks through a real Manifest V3 project end to end.

Chrome Extension vs Bookmarklet: The Capability Gap

Where the two actually diverge:

Keyboard shortcuts. Extensions bind commands to hotkeys, configurable by the user at chrome://extensions/shortcuts. Bookmarklets have no keyboard binding in Chrome. You click them, or you type the bookmark name in the omnibox and press Enter. For a tool used forty times a day, this is decisive.

Internal pages. Bookmarklets cannot run on chrome:// pages, the New Tab page, the Chrome Web Store, or the built-in PDF viewer. An extension with the tabs permission can still read the URL and title of those tabs, because it is not injecting into them — it is asking the browser.

Persistent state. Extensions have chrome.storage, synced across devices. Bookmarklets have nothing; they can write to localStorage of whatever page they happen to be on, which is per-origin and unreliable.

Acting across tabs. An extension can enumerate every open tab and act on all of them. A bookmarklet only ever sees the page it fired on. Anything that operates on a whole window is extension territory.

Cross-origin requests. An extension can declare host permissions and fetch across origins. A bookmarklet inherits the page CORS constraints and is frequently blocked.

UI surface. Extensions get a toolbar icon, a popup, an options page, a side panel, context menu entries, and optionally a DevTools panel. A bookmarklet gets whatever it draws into the current page.

Update path. Extensions update automatically through the store. Bookmarklets require every user to delete the old bookmark and paste a new one. For anything you distribute, this alone rules bookmarklets out.

Distribution. A bookmarklet is a copy-paste and a drag. An extension needs a store listing, a one-time developer registration fee, and a review that takes anywhere from hours to a couple of weeks.

Where the bookmarklet wins: install friction, transparency, cross-browser portability, and no review gatekeeper. Those are not small, and for a personal script they may be everything.

The Content Security Policy Problem That Breaks Bookmarklets

This is the failure mode that surprises people and the biggest change in the Chrome extension vs bookmarklet calculus over the past decade.

Content Security Policy is a response header that tells the browser which scripts are allowed to run on a page. A strict policy — no inline scripts, only scripts from named origins — is now standard practice on security-conscious sites. Chrome applies that policy to bookmarklets. A javascript: bookmark fired on a page with a restrictive script-src is blocked from executing.

The user experience of this is terrible: the bookmarklet does nothing. No error dialog, no explanation, nothing in the UI. The only sign is a CSP violation message in the console, which normal users never open.

The sites where this bites are exactly the ones developers want tooling for: source hosts, issue trackers, social platforms, banking, documentation portals, admin dashboards, and most enterprise SaaS. The direction of travel is one-way — CSP adoption keeps rising, and no site is going to loosen its policy so that bookmarklets keep working.

Content scripts in an extension are not affected. They run in an isolated world with their own CSP context, which is precisely why extensions remain viable for page tooling and bookmarklets increasingly are not. If your script needs to work reliably on arbitrary sites, that single fact decides the Chrome extension vs bookmarklet question before any other consideration.

Two other quiet bookmarklet limitations worth knowing:

• Clipboard writes need a user gesture and a secure context. A bookmarklet click usually qualifies, but the behaviour differs across pages and the async clipboard API is stricter than the old execCommand path it replaced.
• Chrome strips the javascript scheme when you paste a bookmarklet into the address bar, as an anti-phishing measure. It only works from a bookmark, which means every user has to do the bookmark-creation dance manually.

Keyboard Shortcuts: The Deciding Factor for Daily Tools

For any tool you use more than a few times an hour, the trigger method matters more than the feature set.

A bookmarklet trigger is: move hand to mouse, locate the item on the bookmarks bar, click. Roughly one to two seconds, plus the attention cost of a visual search along a bar of similar-looking favicons. It also requires the bookmarks bar to be visible, which many people keep hidden for screen space.

An extension trigger is: press a key combination. A fraction of a second, hands stay on the keyboard, no visual search.

Take the most common example in this category — copying the current page URL. As a bookmarklet, it is one line of JavaScript and it mostly works. As an extension, it is a service worker responding to a command, and it works everywhere including on pages with strict CSP and on internal browser pages. The Ctrl+Shift+C extension is that second version: one keystroke, any tab, clipboard permission only, no network calls, no data collection. The bookmarklet version of the same idea fails silently on a meaningful share of the sites where you would want it.

That is the general pattern. Bookmarklets are fine for tools you invoke occasionally on sites you control or know. They are the wrong shape for tools you invoke constantly on arbitrary pages. See copy URL Chrome extension for the full comparison of approaches to that specific problem.

Distribution, Updates, and Trust

If the tool is only for you, distribution is irrelevant and the bookmarklet wins on effort. If anyone else will use it, the picture inverts.

Shipping a bookmarklet to other people means giving them a string and instructions: create a bookmark, paste this into the URL field, name it, drag it to the bar. Every step is a place people give up. Many chat and email clients mangle the string. Some corporate policies block the javascript scheme entirely through URLBlocklist. And when you fix a bug, every single user has to repeat the whole process.

Shipping an extension means a store listing, a one-time developer registration fee, a review, and then a link that installs in two clicks. Updates propagate automatically within hours. The store page carries a permission list and a privacy disclosure that gives users something concrete to evaluate.

There is a trust asymmetry running in both directions. A bookmarklet is fully readable, so a careful user can audit it in ten seconds — but almost nobody does, and the ones who would are not the ones at risk. An extension is opaque unless the source is published, but it passed a review, its permissions are enumerated, and its behaviour is constrained by the browser rather than by trust.

The strongest position combines them: a small extension with a narrow permission set and public source. That gives you the reviewable code of a bookmarklet and the capability and distribution of an extension. See privacy focused Chrome extensions for how permission scope translates into actual risk.

A Decision Framework: Which One to Build

Work down the list. The first yes settles the Chrome extension vs bookmarklet question for that particular tool.

Build an extension if:

1. It needs a keyboard shortcut. Non-negotiable — bookmarklets have none.
2. It must work on arbitrary sites. CSP will break the bookmarklet somewhere important.
3. It needs to see or act on tabs other than the current one.
4. It needs to persist settings between sessions or across devices.
5. It needs to run without you clicking anything — on install, on a schedule, on a navigation event.
6. Other people will use it. Install friction and the update path both favour an extension by a wide margin.
7. It needs browser-level surfaces — context menu, side panel, DevTools panel, omnibox keyword.

Build a bookmarklet if:

1. It is for you, on sites you already know work.
2. You want it in Chrome, Firefox, and Safari today with no per-browser packaging.
3. The logic is under twenty lines and unlikely to grow.
4. You want it auditable at a glance by whoever you hand it to.
5. You cannot install extensions — a locked-down managed device is the classic case where a bookmarklet is the only option available, assuming the javascript scheme is not also blocked.
6. It is a prototype. Build the bookmarklet first, use it for a week, and port it to an extension only if you keep reaching for it.

That last one is the most useful habit. Most ideas do not survive a week of real use. Prototyping as a bookmarklet costs minutes; prototyping as an extension costs an afternoon. When the bookmarklet earns its place and starts hitting CSP walls or begging for a hotkey, that is the signal to port it — and by then you know exactly what it needs to do.

Frequently Asked Questions

Do bookmarklets still work in Chrome in 2026? Yes, Chrome still runs javascript bookmarks from the bookmarks bar. They fail on any site with a restrictive Content Security Policy and on internal Chrome pages, which covers a growing share of the sites people most want tooling for.

What is the main advantage of a bookmarklet over an extension? Zero install friction and full code transparency. It is a single line of JavaScript you can read, edit, and paste into any browser without a store account, a review process, or a permission prompt, and the same string works in every browser.

Can a bookmarklet have a keyboard shortcut? Not natively in Chrome. Bookmarklets have to be clicked or triggered through the omnibox by name, while extensions can bind commands to real hotkeys at chrome://extensions/shortcuts and let users rebind them.

Why does my bookmarklet fail on GitHub or other large sites? Those sites send a Content Security Policy that blocks inline script execution, and Chrome applies it to javascript bookmarks too. The bookmarklet silently does nothing, with the only evidence being a violation message in the console.

Are bookmarklets safer than extensions? They are more transparent because the code is visible, but they are not inherently safer. A bookmarklet runs with full access to the page it fires on, and pasting one you have not read is exactly as risky as installing an unvetted extension.

Can a bookmarklet read the URL of a chrome internal page? No. Bookmarklets cannot execute on chrome internal pages, the Web Store, or the New Tab page at all. An extension using the tabs API can still read the address and title of those tabs because it queries the browser rather than injecting into the page.

Should I ship my tool as an extension or a bookmarklet? Ship a bookmarklet for a one-off script you use yourself and an extension for anything other people will rely on daily, need a hotkey for, or expect to keep working across sites. Prototyping as a bookmarklet first is a cheap way to find out which you have.

Prototype as a Bookmarklet, Ship as an Extension

The Chrome extension vs bookmarklet decision is mostly a question of audience and frequency. A script you run twice a week on a site you control is a bookmarklet, and building an extension for it is over-engineering. A tool you or anyone else fires dozens of times a day on arbitrary pages is an extension, and shipping it as a bookmarklet means it will silently fail on the sites that matter and can never have a hotkey.

The clearest example of the second category is copying the current page address. Ctrl+Shift+C does it in one keystroke on every tab, including the pages where a bookmarklet quietly does nothing — free, clipboard permission only, no network calls, zero data collection. Install it, and keep the bookmarklets for the experiments.