Bulk image tagging
Tag a whole catalogue in one pass. Drop in a folder, or upload a CSV of image URLs and let PicsTag work through the list — with your asset IDs preserved, so the export drops straight back into your system.
No account. No upload. Runs in your browser.
Tagging one image is easy. Tagging forty thousand is a project.
Every image tool demos beautifully on one photo. The problem is never one photo. The problem is the backlog — the ten years of assets already sitting in a bucket, none of them tagged, all of them technically searchable and practically invisible.
That backlog is what turns metadata from a task into a project, and projects need a budget, and the budget never comes. So the backlog stays.
Two ways to feed it
A folder of local files
Drag them in. The images are read straight from disk into the browser and processed one after another. This is the right mode when the files are on your machine — a shoot, an export from your DAM, a client delivery.
A CSV of image URLs
This is the mode that makes a real catalogue tractable. If your images already live on a CDN, an S3 bucket or an existing DAM, you do not need to download them first. Export a CSV with two columns:
image_url— where the image can be fetchedasset_id— your identifier, carried through to the export untouched
PicsTag works through the rows, and the resulting CSV or JSON joins straight back onto your catalogue onasset_id. No manual reconciliation, no filename matching, no spreadsheet archaeology.
The confidence threshold is what makes bulk work
Bulk tagging is only useful if you do not have to look at every result — otherwise you have automated the easy half and kept the expensive half.
Every predicted tag carries a confidence score, and that score lets you split the batch:
- Set a threshold — 80% is a sane starting point — and accept everything above it in one click. The model is rarely wrong when it is that certain, and you just tagged a large fraction of the batch without reading a word.
- Review what is left, one image at a time, at a size where you can actually judge it. Yes, no, yes, no. This is fast, because you are deciding rather than typing.
- Export. Only tags you accepted are written out. Rejected and un-reviewed ones are dropped, so nothing enters your catalogue unseen.
Where you put the threshold is a real decision with a real trade-off — that is the subject ofhow accurate is AI image tagging.
What will go wrong (and what to do about it)
Honest failure modes, because a bulk run at 3am is a bad time to discover them:
- CORS errors on CSV rows. Browsers cannot fetch images from servers that do not permit cross-origin requests. This is a rule of the web, not a bug in the tool. Fix: use the cloud model (it fetches the URL server-side), or download the files and process them locally.
- 404s and dead URLs. Old catalogues are full of them. Failed rows are marked with an error and can be retried individually — the run does not abort.
- The first run is slow. The models (~250 MB) download once, then are cached by your browser. Image one is slow; image two onwards is fast.
- Speed depends on your hardware. A machine with WebGPU is dramatically faster than one falling back to WebAssembly. Both work.
No quota, because no server
Every cloud tagging API charges per image, which is precisely why bulk tagging a legacy catalogue is quoted as a project rather than done on a Tuesday. PicsTag runs the model on your machine: the ten-thousandth image costs exactly what the first one did, which is nothing.
And with local files, nothing leaves your browser — so the backlog you were never allowed to upload to a third-party service is exactly the backlog you can finally clear.
Frequently asked questions
How many images can I process at once?
There is no hard limit, because there is no server bill and no quota. The practical ceiling is your own machine and your patience: a few hundred images in one run is comfortable, a few thousand is an afternoon. You can press Stop at any point and everything processed so far is kept.
What does the CSV need to contain?
Two columns: image_url (a publicly reachable URL) and asset_id (your own identifier). Header names are matched loosely — image url, Image_URL and imageurl all work. Every other column is ignored.
The images are behind a login or a private bucket. Does that work?
No. The browser fetches each URL directly, so it must be reachable without authentication. For private assets, use signed URLs with a long enough expiry, or download them and drop the files in instead.
Some rows failed to download. What happened?
Usually CORS. A browser cannot fetch an image from a server that does not allow cross-origin requests, which is a rule of the web and not something a tool can bypass. Two workarounds: switch to the cloud model in the settings, where the model fetches the URL server-side instead of your browser, or download the images and process them as local files.
Will the export line up with my existing catalogue?
Yes — that is what the asset_id column is for. It is carried through untouched, so the export can be joined straight back onto the rows you started with.