Local vs cloud AI image tagging — how to choose

There are two ways to get AI to tag your images, and the marketing on both sides is unhelpful. Cloud vendors do not mention that you are uploading your client’s unreleased product photography to their servers. Local-first advocates (we are one) do not always mention that the small model in your browser is genuinely less capable.

So here is the comparison as honestly as we can write it, including the parts where our own default loses.

What each one actually is

Cloud tagging sends your image to a vendor’s server, where a large model looks at it and sends back tags or a description. This is how essentially every commercial image-tagging service works, and how the vision APIs from the big labs work.

Local tagging downloads the model to your browser once and runs it on your own hardware — using WebGPU where the machine supports it, WebAssembly where it does not. The image never goes anywhere. This is newer, and it only became practical recently, when models got small enough and browsers got fast enough.

The comparison

	Local (in-browser)	Cloud vision API
Quality of tags	Good on common subjects. Fixed vocabulary.	Better. Open vocabulary, understands context.
Reads text in images	No	Yes
Conceptual tags (“loneliness”)	No — literal only	Yes
Cost per image	Zero	Per-image fee. It adds up fast at catalogue scale.
Cost at 40,000 images	Zero	A real line item you must get approved.
Your images leave your machine	Never	Always
Usable under NDA / embargo	Yes	Usually not, without a signed DPA
Works offline	Yes, after the first download	No
First-run cost	~250 MB download	None
Speed	Depends on your hardware	Depends on your network and their queue
Rate limits	None	Yes

Where local genuinely loses

Be clear-eyed about this, because it decides real cases.

A small model has a fixed vocabulary. It knows roughly a thousand common categories. Ask it about sourdough and it says bread, confidently. Ask it about a specialised subject — a medical image, an industrial part, a rare species — and it will produce a confident, plausible, wrong word. It has no way to say “I have no term for this”.

It cannot read text in the image. A poster, a quote card, a screenshot, a product label — the words are the content, and the local model is blind to them. A large cloud model reads them.

It has no conceptual layer. It will tell you an image contains an empty office. It will not tell you the image is about remote work. For editorial and stock libraries, where the searches people run are conceptual, that gap is significant.

It is literal to a fault. Cloud models write richer, more usable captions. Compare: local gives you “a plate of food on a table”; a large model gives you “an overhead shot of a rustic sourdough loaf on a wooden board, warm natural light”.

If your job needs any of the four things above, use a cloud model. We would rather tell you that than have you conclude the whole category is useless.

Where cloud genuinely loses

Cost, at any real scale. Per-image pricing is trivial for a hundred images and a budget line for forty thousand. This is precisely why backlogs never get tagged: the estimate arrives, someone does the multiplication, and the project quietly dies.

The upload itself is disqualifying, for a lot of people. Not “uncomfortable” — disqualifying:

• Agencies handling client assets under NDA.
• E-commerce teams with unreleased product photography and an embargo.
• Editorial photographers under embargo.
• Anyone in health, legal or finance whose data processing agreement does not list a new AI vendor.
• Public bodies with data-residency requirements.

For these, “just upload it to the API” is not a trade-off, it is a contract violation. And it is not a rare edge case — it is a large slice of everyone who has a serious image library.

Rate limits and dependencies. Your bulk job now depends on someone else’s uptime, someone else’s queue, and someone else’s pricing decisions.

How to actually choose

Ask three questions, in this order:

1. Am I allowed to upload these images? If no, the decision is made. Use local. Everything else is hypothetical.

2. Do I need what only the big model can do? Text in images, conceptual tags, unusual subjects, rich prose captions. If yes, and you are allowed to upload, use cloud — the quality gap is real and you will feel it.

3. How many images, and what does a wrong tag cost me? Ten thousand images of common objects, where a wrong tag means a photo shows up in the wrong search? Local, with a review pass. Two hundred hero images on a live storefront, where a wrong tag is a customer complaint? Cloud, and review those too.

The pragmatic answer: use both

The split that works in practice:

• Local for the bulk pass. Everything gets a baseline: literal tags and a caption, free, offline, no upload. This is the layer that turns an unusable library into a usable one, and it is the layer whose cost has been making it not happen.
• Cloud for the images that earn it. The hero shots, the campaign images, the ones with text in them, the ones a customer will actually see. A few hundred images through a good model costs very little; forty thousand costs a project.

This is why PicsTag ships both: the local model is the default because it fits the bulk case and asks nothing of you, and you can switch to a cloud model in the settings with your own OpenRouter API key. Your key, your bill, your images going straight from your browser to them — we are not in the middle, and we do not take a cut.

That last part is deliberate. A tool that owns the API relationship has a quiet incentive to route you to the expensive path. We would rather the trade-off stay yours, and stay visible.