Web tool, browser extension, or bookmarklet: which one your task actually needs
A comparison of the three lightest ways to automate a small task in a browser, and how to tell which one fits before you commit to it.
Someone has a small repetitive task and decides to automate it. The next question is what form the solution should take, and the usual answer is "an extension", because extensions are the most visible option. It is frequently the wrong answer.
There are three lightweight shapes available in a browser, and they differ in ways that matter a lot after the first week: what they can reach, what they cost you continuously, and what you have to trust.
The three options, briefly
A web tool is a page you open, use, and close. You paste something in or upload something, it does the work, you take the result. It has no access to anything except what you hand it.
A bookmarklet is a bookmark whose address is a small piece of JavaScript instead of a URL. Clicking it runs that code on the page you are currently looking at. It sits in your bookmarks bar, it is a few lines long, and it does nothing until clicked.
A browser extension is installed software. It has a manifest, declared permissions, an update channel, and — depending on those permissions — the ability to run on pages automatically, in the background, whether or not you asked.
What each one can reach
This is the difference that determines most decisions.
A web tool can only see what you give it. That is a real limitation and also its main virtue: it cannot read your other tabs, it cannot see your browsing, and it cannot do anything when you are not on it. If the task is "transform this text I have" or "convert this file", the limitation costs nothing.
A bookmarklet can see and change the page you are on, at the moment you click it, and not otherwise. This is the narrowest possible access for a task that needs the current page — meaningfully narrower than the equivalent extension, because it happens only on demand and leaves nothing running.
An extension can, depending on permissions, run on every page you visit automatically, keep a background process alive, react to browser events, store data, and persist across sessions. That reach is what makes extensions powerful and what makes them the heaviest choice.
What each one costs continuously
The costs are asymmetric in a way that is easy to miss when choosing.
| Web tool | Bookmarklet | Extension | |
|---|---|---|---|
| Cost when not in use | None | None | Memory, sometimes CPU, on every page |
| Setup effort | Bookmark it | Drag to bookmarks bar | Install, grant permissions |
| Updates | Automatic, invisible | Manual, never breaks silently | Automatic, can change behaviour |
| Works offline | Only if built to | Yes | Yes |
| Sync across devices | Nothing to sync | Via bookmark sync | Via browser account |
| What you must trust | The page, when you use it | The code, once, readable | The publisher, ongoing |
The last two rows deserve more attention than they get.
An extension's automatic update channel is a genuine convenience and a genuine risk. Extensions get sold. A well-behaved tool with a real user base is a valuable asset, and a change of ownership can turn it into something quite different in one update that installs without asking. This is not hypothetical — it is one of the most common ways browser users end up running software they never chose to run. Checking the newest reviews before installing is a partial defence.
A bookmarklet, by contrast, is code you can read once, in full, before you use it, and it never changes on its own. For a small task, that is a strong property.
Choosing between them
The question that resolves most cases: does the task need the page you are currently on?
If no — you are transforming text, converting a file, calculating something, generating something — a web tool is the right shape. It is the lightest option, it costs nothing when unused, and it requires no trust beyond the moment you use it. Reaching for an extension here is adding a permanent installed component to solve an occasional problem.
If yes, ask a second question: how often, and does it need to happen without being asked?
- On demand, a few times a day, on a page you are looking at → a bookmarklet handles this, with the least possible reach.
- Automatically on every relevant page, or often enough that even a bookmark click is friction, or it needs to remember things between sessions → this is what extensions are for.
A useful sanity check on the last one: if the extension you are imagining would work fine as a button you press, the button is probably enough.
Where each one genuinely wins
Web tools win at file and text transformation, at anything you do occasionally, at anything you want to use on a computer that is not yours, and at anything where you would rather not install software at all. They also win on a borrowed or locked-down machine, where installing an extension is not permitted — a real constraint on school and work computers.
Bookmarklets win at small, on-demand changes to the current page, and at situations where you want to know exactly what the code does. They are also the only option that works identically across desktop browsers with no install step. Their weaknesses are real though: they are awkward on mobile, many sites' security policies block them, and there is no good place to store settings.
Extensions win when the work has to happen without being asked, when it needs to react to browser events, when it needs persistent settings, or when the interaction belongs in the toolbar rather than in a page. When a task genuinely fits this shape, nothing else comes close — the mistake is only in reaching for it by default.
TabVault is a fair example of a task that genuinely needs the third option. Reading a page's scroll position and a video's current timestamp requires being on that page at the moment you save it — no separate tab can see either — and the saved set has to reopen from the toolbar rather than from somewhere you would first have to navigate to. A web page could not do it, and a bookmarklet could not remember anything between uses.
The order to try things in
For a task you have decided is worth automating:
- Check whether the browser or OS already does it. Keyboard shortcuts, text replacement, and reader mode cover more than people expect, and cost nothing.
- Try a web tool. If the task is a transformation of something you can paste or upload, stop here.
- Try a bookmarklet. If it needs the current page but only when you ask, stop here.
- Build or install an extension. Only if the task genuinely needs to be automatic, persistent, or event-driven.
Working down this list rather than starting at the bottom tends to produce a browser that stays fast, and a set of tools where each one is only as powerful as its job requires. That principle — use the lightest shape that does the job — is also how projects get chosen here, and it is why the studio publishes both web tools and extensions rather than turning every idea into an install.
One thing that applies to all three
Whatever shape you choose, prefer the version that does its work in your browser over the version that sends your data to a server.
For a great many small tasks — reformatting text, converting between formats, resizing an image, calculating something — there is no technical need for the data to leave the machine. Modern browsers can do all of it locally. When a tool sends your content to a server anyway, that is a choice someone made, and it is worth knowing it was made.
It is also a reasonable thing to ask about. A tool that processes locally will usually say so plainly, because it is an advantage worth advertising. If a tool is vague about where your data goes, treat the vagueness as the answer.