How in-browser AI works, and why your images stay local
The short answer
ImgTagger sends the AI model to your browser instead of sending your images to a server. The tagger downloads a WD14 model from Hugging Face when you first open it, stores it in your browser if it can, and runs it on your own CPU using ONNX Runtime Web and WebAssembly. Your images are read from disk into the tab's memory and never uploaded. The costs are a large first download, heavy memory use and high CPU load while tagging, and you can check every network request yourself in DevTools.
Most online AI image tools work by uploading your pictures to a server, running a model there, and sending back the result. ImgTagger works the other way round. The model is delivered to your browser once, and all the analysis happens on your own computer. Your images are never sent anywhere. Below is what gets downloaded, where it is stored, what it costs your machine, and how to check it yourself.
What happens when you open the tagger
When you load the auto-tagger, the page goes through these steps:
- The page loads. This includes our HTML, scripts and styles from imgtagger.com (served through Cloudflare), the JSZip library from cdnjs (used to build ZIP downloads), and Google's ad script.
- The engine loads. ONNX Runtime Web 1.22.0 fetches its WebAssembly files from the jsDelivr CDN.
- The model is found or fetched. The page looks for the selected model in your browser's IndexedDB storage, in a database called
onnx-model-cache. If it isn't there, it downloadsmodel.onnxand the tag listselected_tags.csvfrom the model's Hugging Face repository and saves both. The links are pinned to one fixed revision of each file. If the browser won't let the page save them, the model still loads and simply downloads again next time. - Workers start. The page starts a pool of background workers. Each one gets its own copy of the model and prepares it to run.
- Ready. From here on, tagging needs no network connection at all.
The download in step 3 is the big one. The three models are all by SmilingWolf and published on Hugging Face. The two v2 model cards state the Apache-2.0 license; the ViT repository doesn't state one.
| Model | Download size | Tags it can output |
|---|---|---|
| ConvNeXt V2 (default) | 388 MB | 9,083 |
| Swin V2 | 455 MB | 9,083 |
| ViT | 365 MB | 6,549 (no character tags) |
Our WD14 model comparison explains the differences between them.
What happens when you tag an image
- You drop or choose files. The browser reads them from your disk into the tab's memory with the standard FileReader API. Nothing is uploaded at this point or later.
- For each image, the page draws it onto an invisible canvas. It pads the image to a square with white, resizes it to 448×448 pixels, and turns the pixels into a list of 602,112 numbers (448 × 448 × 3 color channels).
- Those numbers are handed to a free worker. This hand-off happens inside your browser's memory, not over the network.
- The worker runs the model and returns a confidence score for every tag in the list.
- The page keeps the tags that clear your confidence threshold, drops anything on your blacklist, and adds the rest to the image.
The raw scores are kept in memory for each model you use. If you change the threshold or blacklist and run again, the model doesn't need to run a second time. Your tags, edits and images exist only in that tab until you download them as a ZIP.
ONNX Runtime Web and WebAssembly, in brief
ONNX is an open file format for trained AI models. A model trained in one framework can be exported to ONNX and run anywhere with an ONNX runtime. ONNX Runtime Web is the browser version of ONNX Runtime, Microsoft's open-source engine for running these models.
WebAssembly (WASM) is a compact code format that browsers can run at close to native speed. It runs inside the same security sandbox as any other web page code, so it can't read your files unless you hand them to the page. ONNX Runtime Web can use several "backends". ImgTagger uses the WebAssembly backend, which runs on your CPU. The model doesn't run on your graphics card.
The worker pool: how many and why
A Web Worker is a background thread that a page can start. Work done in a worker doesn't freeze the page, and several workers can run at once on different CPU cores. ImgTagger runs one model engine per worker, each using a single WebAssembly thread, and tags several images in parallel.
The pool size is 80% of the number your browser reports in navigator.hardwareConcurrency, rounded down, with a minimum of 4 and a maximum of 20. That number is the count of logical processors, which on many CPUs is twice the number of physical cores.
| Logical processors reported | Workers started |
|---|---|
| 2, 4 or 6 | 4 |
| 8 | 6 |
| 12 | 9 |
| 16 | 12 |
| 24 | 19 |
| 32 or more | 20 |
Some browsers and privacy settings report a lower number than your real processor count. If so, you get a smaller pool, but never fewer than four workers.
The costs of running AI locally
A large first download
Each model is a one-time download of 365 to 455 MB, as long as your browser keeps it. If you try all three, that is about 1.2 GB of downloads and the same amount of browser storage. On a metered or slow connection, pick one model and stick with it.
Memory
This is the biggest cost. Every worker holds its own copy of the model, and the page keeps at least one more. Multiplying the model size by the number of workers gives a rough lower bound for memory use. The real figure is higher, because the model also needs working memory while it runs.
| Workers | ConvNeXt V2 (388 MB) | Swin V2 (455 MB) | ViT (365 MB) |
|---|---|---|---|
| 4 | ~1.6 GB | ~1.8 GB | ~1.5 GB |
| 6 | ~2.3 GB | ~2.7 GB | ~2.2 GB |
| 12 | ~4.7 GB | ~5.5 GB | ~4.4 GB |
| 20 | ~7.8 GB | ~9.1 GB | ~7.3 GB |
This is an estimate from file sizes, not a measurement, but the pattern holds: a machine with many processors starts many workers and needs a lot of RAM. There is currently no setting to run fewer workers. On a machine with 8 GB of memory or less:
- Close other browser tabs and memory-heavy apps before tagging.
- Use ViT, the smallest model, if you don't need character tags.
- Avoid switching models back and forth. Models you have loaded stay in the page's memory until you reload the tab, so reload after switching.
If the tab runs out of memory, the browser usually shows a crash page. Reload and try again with less open.
CPU, heat and battery
With 80% of your logical processors busy, a large batch keeps most of your CPU working flat out. Expect fans to spin up and laptops to get warm, and plug in for big batches, because a long run drains a battery quickly. Browsers also throttle hidden tabs to save power, so a batch can slow down or pause until you switch back to it.
Where the model is stored, and how to delete it
Downloaded models live in your browser's IndexedDB, a storage area that belongs to imgtagger.com only. Other websites can't read it. There are two ways to remove them.
In the app: click Delete downloaded models under Advanced in the tagger's Auto-tags and confirm. This deletes every cached model and tag list. The next time you load the tagger, the selected model downloads again.
In your browser: deleting imgtagger.com's site data removes the models too.
- Chrome and Edge: click the icon to the left of the address bar, open the site settings, and delete the site's data.
- Firefox: click the padlock in the address bar and choose to clear cookies and site data.
- Safari: open Settings, go to Privacy, choose Manage Website Data, search for imgtagger.com and remove it.
Clearing all site data also resets your saved settings, such as the blacklist and prepend tags, which are kept in the browser's local storage. If you want to see the cached models first, open DevTools, go to the Application tab (Storage in Firefox) and expand IndexedDB.
What the site connects to
| Destination | What it fetches | When |
|---|---|---|
| imgtagger.com (served through Cloudflare) | Pages, scripts, styles and the worker script | Every visit |
| cdnjs.cloudflare.com | The JSZip library | Tool pages |
| cdn.jsdelivr.net | ONNX Runtime Web files (tagger) and face-api.js (face sorter) | Tool pages |
| huggingface.co and its hf.co download servers | Model file and tag list | Opening the batch tagger or switching models, or adding a picture to a single-picture tagger, unless that model is already cached |
| justadudewhohacks.github.io | face-api.js model weights | Opening the face sorter |
| Google ad services, and the ad content they load | Ads | Pages that show ads |
| Google Analytics (googletagmanager.com, google-analytics.com) | Visit statistics: page viewed, device and browser type, approximate location | Every page view |
Apart from ads and analytics, every request on that list is a download. Our code never sends your images, thumbnails, filenames, tags or caption files to any of these services, or anywhere else. The duplicate finder and color fixer don't download a model at all. They do their work with ordinary JavaScript and the browser's canvas.
The ads are served by Google AdSense. Like the ads on any ad-supported site, they run Google's scripts on the page and may use cookies. Google Analytics records which pages are visited so we know what to improve. It receives page addresses, not your files. Our code never passes your images or tags to either service. Our privacy policy explains both in full. Their requests show up in the same Network tab as everything else, so you can inspect them too.
Verify it yourself in DevTools
You don't have to take our word for any of this. Your browser's developer tools show every request a page makes. These steps work in Chrome, Edge and Firefox:
- Open the tagger. Press
F12, orCtrl+Shift+Ion Windows and Linux, orCmd+Option+Ion a Mac. - Select the Network tab, then reload the page so the list captures everything from the start.
- Wait until the tagger says the model is ready. On a first visit you will see a request for
model.onnxon huggingface.co, followed by a very large download from a hf.co server. On later visits neither appears, because the model comes from IndexedDB. - Click the clear button in the Network toolbar to empty the list.
- Drop in a folder of images and click Auto-tag all.
- Type
method:POSTin the filter box. This shows only requests that send data out. Small POSTs to google-analytics.com are visit statistics. If anything else appears, click it and open its Payload or Request tab to see what it sent. Compare its size with your images: a request carrying a photo would be at least as big as the photo. - Clear the filter and look at the full list. During tagging you should see nothing new apart from ad and analytics traffic.
In Chrome and Edge you may also see entries that start with data:image. These are your images being displayed from memory, not network requests, and the filter options can hide them.
For a stronger test, wait until the model is ready, then change the Network tab's throttling menu from "No throttling" to "Offline". Now add images and tag them. Tagging keeps working, because nothing in the tagging step needs the network.
Browser support caveats
- Use a current browser. The tagger needs WebAssembly and module Web Workers, and uses IndexedDB to cache the model when it is available. Recent versions of Chrome, Edge, Firefox and Safari support all of them.
- Private windows may not keep the model. Private and incognito modes often limit storage or delete it when you close the window, so the model may download again every time.
- Storage depends on free disk space. Browsers only let a site store so much, based on your free disk space. If the model can't be saved, the tagger still works, but it downloads the model again on your next visit.
- Phones and tablets are a poor fit. Even the minimum pool of four workers needs about 1.5 GB of memory for the model alone, which many phones and tablets can't spare for a single tab. A desktop or laptop is the practical choice.
- Blocked domains break loading. If an extension, firewall or workplace network blocks cdn.jsdelivr.net or huggingface.co, the tagger can't load its engine or model.
Once the tagger is running, the rest of your workflow stays local too. Our image dataset workflow shows how the tools fit together.
Run WD14 tagger models on a whole folder, then search, filter and bulk-edit the tags before exporting .txt caption files. It runs entirely in your browser. Open the Batch WD14 Tagger & Editor.
Frequently asked questions
Does ImgTagger work offline?
Partly. Once the page and model are loaded, tagging and editing work without a connection. The page itself still has to be loaded from the internet, and there is no installable offline version. If you reload while offline, the page won't open.
Can Hugging Face see which images I tag?
No. Hugging Face only receives an ordinary download request for the model file and tag list, like any file download, including your IP address. That happens before you add any images, and the request contains no image data.
What happens to my tags if I close the tab?
They are gone. ImgTagger doesn't save images, tags or edits anywhere, which is part of what keeps them private. Download a ZIP of your .txt files before you close the tab or reload the page.