Let me start by disqualifying myself. I built toolz.dev. Any comparison I write between my site and someone else's is marketing, and you should read it that way. The only thing I can offer that a neutral reviewer can't is the source — I know exactly what my tools do, what they send, and where they fall over, because I wrote the bugs.
So this isn't a scorecard where I win. It's the comparison I'd want if I were you: what a browser-based tool site can do that a server-based one structurally cannot, where the server-based ones genuinely beat me, and — most useful of all — how to check any of these claims yourself in about fifteen seconds, including mine.
TL;DR: toolz.dev has 57 tools, not the "600+" you'll see on some tool sites (including, until I fixed it, my own marketing copy). Nearly all of them run entirely in your browser, which means your files and data never reach a server — that's the real, structural difference from TinyWow, SmallPDF, and iLovePDF, and it's the only claim here you don't have to take on faith. Open DevTools → Network and watch. Where I lose: no PDF tools on the web app at all, no AVIF or animated output, no batch processing, and there is a usage-metering system (5/day guest, 20/day registered) wired into 44 of the 57 tools. Best tools to start with: JSON Formatter, JWT Decoder, Text Diff, Regex Tester.
Let's Deal With the Tool Count First
The draft of this article that sat in my repo for months opened with "over 600 tools." I counted. There are 57.
I'm not going to pretend that was a typo. It's the standard inflation in this category, and I'd copied it without checking. When I actually enumerated the registry in July, I found 57 tool IDs, and I found that an earlier article of mine linked to about fifteen tools that had never existed — svg-optimizer, javascript-minifier, color-converter, merge-pdf. Confident links to 404s. That's the mistake I'm least proud of on this site, and it's why the number in the TL;DR is a number I recount rather than remember.
The reason I'm making a thing of it: tool counts are the least meaningful metric in this entire category, and everyone leads with them. A "600 tools" site usually means one templating engine and 600 landing pages — the same case converter with 40 URLs for "uppercase converter," "lowercase converter," "title case converter." It's a programmatic SEO tactic, not a product. Fifty-seven tools I can name is a more honest description of a smaller thing.
What actually matters is whether the tool you need is good, and where your data goes when you use it.
What Is the Real Difference Between Browser Tools and Server Tools?
This is the whole argument, so let's be precise about it rather than waving at "privacy."
Server-side (how TinyWow, SmallPDF, iLovePDF, and most PDF and image sites work): you upload the file, it travels to their infrastructure, their code processes it, and they send back a result. Your file exists on someone else's disk, at least temporarily. Their privacy policy governs what happens next, and their retention window — usually a couple of hours, per their own docs — governs how long. To be fair to them: these are established companies with real privacy policies and real compliance obligations, and "temporarily on their server" is not the same as "leaked."
Client-side (how nearly all of toolz.dev works): the page loads JavaScript, and that JavaScript does the work on your machine. There's no upload step because there's nowhere to upload to. The file never leaves.
The distinction that matters isn't that one company is trustworthy and the other isn't. It's that client-side processing removes the need to trust anyone at all. A privacy policy is a promise. An architecture that never transmits your file is a fact you can verify. Those are different categories of assurance, and only one of them survives a company being acquired, breached, or changing its terms.
Here's how to check, on any tool site including mine:
- Open DevTools (F12) → Network tab.
- Use the tool on a real file.
- Look for a POST with your file in the payload.
If you see your file going out, it's server-side. If the Network tab stays quiet, it isn't. Then go further: turn off your Wi-Fi and use the tool again. A client-side tool keeps working. A server-side one dies instantly. That test takes five seconds and it cannot be faked by marketing copy.
Try it on toolz.dev. If I'm lying, you'll know before you finish reading this paragraph.
Where Does Toolz.dev Actually Lose?
I'd rather you hear this from me than discover it mid-task.
There are no PDF tools. This is the big one. A third of the articles in my own content backlog cheerfully link to "merge PDF" and "split PDF" tools on toolz.dev, and those tools do not exist. If you're here to merge a PDF, use SmallPDF, iLovePDF, or Stirling PDF — Stirling in particular is self-hostable and open source, which means you get the privacy property without needing to trust me either. I'm not going to send you on a wild goose chase through my site so I can keep you on it.
No batch processing. Every image tool here handles one file at a time. TinyWow will do twenty. If you're processing a product catalog, that difference is your whole afternoon, and it's a real reason to use something else.
No AVIF, no animated output. The Format Converter writes PNG, JPEG, and WebP. That's a hard limit of the browser's canvas encoder — no browser can encode AVIF from a canvas — but the limit is still mine to own. Server-side converters run avifenc and simply do it.
Client-side is slower for heavy work. Your laptop is not a datacenter. For genuinely compute-heavy operations, server-side wins on wall-clock time. I think the tradeoff is worth it for most things. For some things it isn't.
The background remover is not AI. It samples the top-left pixel and deletes everything within a color-distance threshold of it. On a flat studio background it's great. On hair, on a gradient, or when your subject shares a color with the backdrop, it will fail badly, and remove.bg will crush it. The tool's own UI says as much.
Some type inference is lossy. The CSV to JSON converter turns 07102 into 7102, because a zip code looks exactly like a number to a regex. I've written about this at length; it's a real defect, not a quirk.
About "Free" — The Part Most Comparisons Get Wrong
Every tool site says it's free. Here's what "free" means here, precisely, including the part that isn't flattering.
Right now, every one of the 57 tools is free and none is marked premium. No watermarks, no signup wall, no credit card.
But there is a usage-metering system in the codebase, and I'm not going to leave it out just because it's inconvenient for the story. It works like this: 44 of the 57 tools call a checkUsage endpoint before they run. The seeded default policy is 5 uses per tool per day for guests, 20 for registered users, unlimited for paid. There is a /pricing page, and when a limit is hit, a toast appears with an Upgrade button.
So: does toolz.dev have usage limits? The infrastructure exists, the policy is seeded, the plumbing is wired into most tools, and there is a paid tier it's designed to sell. I'm telling you it's there rather than claiming a purity I can't back up.
There are two things worth knowing about how it behaves. First, it fails open — if the check can't reach the backend, the tool runs anyway. That's deliberate, so the desktop app works offline. Second, what gets sent is not your data: the request carries a tool ID and a browser fingerprint, and the logging call sends metadata like inputLength — the length of your input, never the input. Your JSON, your CSV, your image: those stay local regardless, because the tool that processes them runs locally.
That's a real distinction, and also exactly the kind of distinction a site owner would draw to make himself look better. So verify it in the Network tab, same as everything else.
Meanwhile the honest answer to "how can this be free" isn't nobility, it's arithmetic: if your device does the processing, my server costs are a static site and a small API. There's no GPU bill, no storage for uploaded files, no egress. That's why the free tier is sustainable — not because I'm generous, but because you're paying in CPU cycles you already own.
What Should I Actually Use, Per Job?
The genuinely useful version of a comparison article. Some of these send you elsewhere.
| Job | Use | Why |
|---|---|---|
| Format/inspect JSON | JSON Formatter | Local, so paste prod payloads safely |
| Decode a JWT | JWT Decoder | Tokens are credentials — never paste into a server tool |
| Diff two configs | Text Diff | Local, no upload |
| Validate K8s YAML | YAML Validator | Single-doc only — see below |
| Convert an image to WebP | Format Converter | Fine for one file |
| Convert 200 images | Squoosh CLI, or cwebp |
Batch beats any web UI |
| Merge or split a PDF | Stirling PDF, iLovePDF | I don't have PDF tools |
| Cut out hair from a photo | remove.bg | My remover is a color key |
| Strip EXIF from a photo | Any tool here that re-encodes | Canvas drops metadata for free |
The YAML row needs a footnote, because it's the sharpest known bug on the site: the validator calls yaml.load(), which accepts exactly one document. Feed it a multi-document Kubernetes manifest — the ----separated kind that is the entire reason anyone validates YAML — and it errors with "expected a single document in the stream." The fix is loadAll(). It's on the list. Until it ships, that tool fails at the job its own audience needs most, and you should know that before you rely on it.
How Do I Evaluate Any Tool Site?
Take this with you and use it on me.
1. Watch the Network tab. Covered above. It's the only claim in this entire category that's independently verifiable in five seconds, which is why almost nobody tells you to do it.
2. Ask who pays. Free + server-side processing = real hosting costs. Somebody's covering them, with ads, tracking, data, or a conversion funnel. That's not automatically sinister, but "how does this make money" has an answer, and if you can't find it, you might be it.
3. Read the retention line, not the headline. "We delete your files" is not a claim — "we delete uploaded files after two hours" is. Most reputable server-side tools state a window. Look for the number.
4. Test the ugly case first. Not the demo file. Your 500-page PDF, your 200k-row CSV, your YAML with four documents in it. Tools are built and demoed on happy paths; you'll live in the edge cases. I found half the bugs listed in this article that way, on my own site.
5. Count nothing. Not tools, not "trusted by," not stars. If a site leads with a number, that's the metric it's optimizing, and it usually isn't quality.
Frequently Asked Questions
How many tools does Toolz.dev actually have?
57, as of this writing. Earlier versions of this site's marketing said "600+", which was wrong and has been corrected. The count comes from the tool registry in the codebase and I recount it rather than trusting the last number I wrote down.
Is Toolz.dev really free?
Every one of the 57 tools is currently free, with no watermarks or signup required. There is a usage-policy system in the backend seeded at 5 uses per tool per day for guests and 20 for registered users, with unlimited for a paid tier, and 44 of the 57 tools call that check before running. It fails open if the backend is unreachable. So "free" is true today, and there's a metering system built to change that — you should know both.
Does Toolz.dev send my data anywhere?
Your actual content — files, JSON, images, text — is processed in your browser and isn't transmitted. Most tools do send a usage ping containing a tool ID, a browser fingerprint, and metadata such as the character length of your input, never the input itself. Verify all of this yourself: open DevTools, go to the Network tab, and use any tool.
Is Toolz.dev better than TinyWow or SmallPDF?
For different jobs. For developer utilities on sensitive data — JSON, JWTs, config diffs — the browser-only architecture is a real advantage, since nothing is uploaded. For PDF work, they beat me outright, because toolz.dev has no PDF tools at all. For batch image processing, they beat me too, since I process one file at a time.
Why does Toolz.dev have no PDF tools?
It just doesn't — the tools were planned and never built, and several older articles on this blog link to PDF tools that return 404s. For merging, splitting, or compressing PDFs, use Stirling PDF (open source and self-hostable, so you keep the privacy property), iLovePDF, or SmallPDF.
Is client-side processing slower than server-side?
For most utility work, no — formatting JSON or converting a timestamp is instant either way, and you save the upload round trip entirely. For genuinely heavy operations, a dedicated server with a GPU will beat your laptop. The tradeoff is speed against never transmitting your data, and which one wins depends on the job.
Do the tools work offline?
Once a tool page has loaded, most keep working with no connection, because the processing runs on your device. The usage check fails open on network error specifically so this holds. Turning off your Wi-Fi and watching the tool keep working is also the simplest possible proof that it isn't uploading anything.
What are the best free online developer tools?
The most useful free developer tools are the ones you reach for daily: a JSON formatter, a JWT decoder, a text and code diff, Base64 and URL encoders, a timestamp converter, a regex tester, and hash and UUID generators. Toolz.dev focuses on this developer-utility category and runs each one in your browser, so the best test of any such tool is whether it keeps working with your network disconnected.
Are online developer tools safe to use?
It depends entirely on where the processing happens. A tool that uploads your input to a server can log or retain it, which matters for tokens, private keys, and config files; a browser-only tool never transmits the content at all. Before pasting anything sensitive, open your browser's Network tab and confirm no request is sent, or simply turn off your Wi-Fi and check the tool still works.
Can I use the output commercially?
Yes. Anything you produce with these tools is yours, with no restrictions or attribution requirements — resized images, formatted code, generated UUIDs, converted files.
The Short Version
I can't give you an unbiased comparison of my own site, so I've given you the next best thing: the specific claims, the specific failures, and the test that settles it without my involvement. Open the Network tab. Turn off your Wi-Fi. Believe what you see rather than what I wrote.
What toolz.dev is: 57 developer utilities that run in your browser, free, no signup, no upload. What it isn't: a PDF suite, a batch processor, an AI cutout tool, or 600 of anything. If the tool you need is on the list, the architecture gives you something a server-side competitor structurally cannot. If it isn't, I've named the sites that will do it better.
Start with the JSON Formatter or the JWT Decoder. If you want the reasoning behind the privacy argument in more depth, it's in the data privacy guide. For the tools I reach for weekly, there's the developer productivity guide and the web developer toolkit.
