DEV Community: Mindutil

Half of my AI directory is labeled "free". 88% of those listings were never claimed.

Mindutil — Sat, 31 Oct 2026 00:36:14 +0000

I run a directory with 4,323 AI tool listings. Every row has exactly one pricing label: free, freemium, or paid. On paper the split looks healthy:

free: 2,198 (50.8%)
freemium: 1,425 (33.0%)
paid: 700 (16.2%)

For a site whose main feature is "filter by price", those are the numbers I care about most. Then I asked a different question: how many of these rows has anyone actually confirmed?

Each listing can carry a verified badge, which means the vendor went through a claim flow and said "yes, this is us". 614 of 4,323 do. That is 14.2%. The split by pricing tier is where it gets interesting:

Label	Listings	Verified	Verified rate
free	2,198	261	11.9%
freemium	1,425	225	15.8%
paid	700	128	18.3%

Free listings are the least verified segment, paid listings the most. I am not going to pretend this is causal. This directory has produced 4 outbound clicks in total, so nothing here is statistically impressive. But the direction makes sense: a paid product has revenue, a support inbox, and someone whose job includes checking listings. A free tool often has one person, no budget, and no reason to care that a directory in another timezone has the wrong price attached to it.

The uncomfortable part is that "free" is the label readers trust most. It is the first filter people apply, and it is the one applied to the listings that nobody has checked.

Where the label actually comes from

The pricing label is inferred, not declared. It comes from the text that arrived with the listing: vendor marketing copy, aggregator feeds, and the crawl itself. So "free" means "the page said free when it was crawled", not "there is a usable free tier with a published limit".

That gap is easy to underestimate. While hand-writing 20 tool pages last week, I hit three failure modes that no automated pass had caught:

Version drift. The Adobe Firefly entry still named Firefly 3. The current flagship is Firefly Image Model 5, two generations later.
Product merging. One row had collapsed Nano Banana 2 (gemini-3.1-flash-image) and Nano Banana Pro (gemini-3-pro-image) into a single tool, with one set of limits.
Conflicting prices. Google AI Plus appeared at both $4.99 and $7.99 across 2026 sources. I wrote "unconfirmed" instead of picking the friendlier number.

All three are the kind of error that only surfaces when a human opens the vendor's pricing page and reads it.

Unverified rows rot in predictable ways

The 85.8% of rows without a verified badge are not all wrong. Most are just fine. But the drift follows patterns:

Stale names. Products rename themselves faster than feeds update.
Merged or split products. Two tools become one, or one tool becomes a tier of another, and the old row keeps collecting traffic.
Dead tools. 405 rows (9.4% of the directory) sit in a discontinued category. Some are genuinely shut down; others are dormant and might come back.

There is also a category-level version of the same problem. Of 92 category pages, 3 currently have zero tools: New AI Tools, Aixploria Selection, and Programming. They still render, and they are still in the sitemap. That is a thin page I created by accident, and it is the sort of thing a crawler is right to ignore.

Related: the average tool sits in 1.62 categories, and 2,100 of 4,323 rows (48.6%) are in more than one. Overlaps are normal, but they also mean a single bad row can produce several bad pages.

Freshness is a number, not a vibe

The "new tools" page is the one most likely to lie by omission, so I started measuring it:

22 listings were published in the last 30 days.
0 were published in the last 7 days.
The newest row is dated 2026-10-18, which is 13 days old today.

For a directory fed by crawling, that is not a disaster, but it does mean the page cannot honestly present a daily "fresh arrivals" feed. The useful metric is not "did the crawl succeed" but "how many rows did this run add or change" — a crawl that succeeds with zero additions is a silent outage.

Three changes that followed

Treat the pricing label as a claim. Store the source and the date it was read next to the value. "Free, checked 2026-10-30" is a different statement from "free".
Measure verification per segment, not overall. The headline 14.2% hides a real 11.9% versus 18.3% gap, and that gap tells you where to look first.
Prune and mark. A discontinued category that is visible is better than dead rows scattered through live categories, and empty category pages should be noindexed until they have something on them.

None of this fixes the underlying economics: free listings will always have the weakest data, because nobody is paid to keep them accurate. The best I can do is stop presenting an inferred label as a verified fact, and show readers which rows have been checked.

The free list, such as it is: https://aiverse.mindutil.com/free-ai-tools?utm_source=devto&utm_medium=social&utm_campaign=sideproject

I fact-checked the free tiers of 20 AI tools. Most listings were wrong.

Mindutil — Fri, 30 Oct 2026 00:32:11 +0000

I run a small AI tools directory - 4,323 entries, filterable by pricing. For the first month, almost every tool page was built from a single sentence of upstream text plus a template paragraph. That is the standard scaled-content setup, and it is wrong in ways that are easy to measure.

So I picked the 20 highest-traffic pages (211K to 414K reads each in the source data) and rewrote them from primary sources: vendor pricing pages, docs changelogs, model cards, and - where the vendor site was unreachable from my network - two or three dated 2026 secondary sources cross-checked against each other. Every claim now carries a source URL and a fetch date.

Three error classes came up over and over. None of them were typos.

1. Version drift: the listing describes a product two generations old

The Adobe Firefly entry still said "Firefly 3". The current flagship image model is Firefly Image Model 5, announced at Adobe MAX in October 2025, with native 4-megapixel output and broad availability since early 2026. The page also described Firefly as an image tool, while the web app now covers video, audio, vector and Boards.

This is not cosmetic. Firefly's paid tiers are published (Standard $9.99/mo with 2,000 credits, Pro $19.99 with 4,000, Pro Plus $49.99 with 10,000, Premium $199.99 with 50,000), and standard image and vector generations are unlimited on any paid plan - credits get spent on premium models at 10 per Image 5 generation and 100 per second of 1080p video. A reader who budgets against the old listing buys the wrong tier.

2. Model merging: two products collapsed into one row

One entry mixed Nano Banana 2 (gemini-3.1-flash-image) with Nano Banana Pro (gemini-3-pro-image). They are different tiers with different prices. Per-image API pricing on the 2 line runs $0.067 at 1K, $0.101 at 2K and $0.151 at 4K, and Nano Banana 2.1 - GA on 2026-10-06 - roughly halves that to $0.0336, $0.0504 and $0.113.

Merging them is how a directory ends up telling people a model costs twice what it does.

3. Confident numbers the vendor never published

Google's free image-generation allowance is published as roughly 20 images a day on the basic tier, 50 on Plus, 100 on Pro and 1,000 on Ultra - with Google itself warning the caps change often. Fine. But the price of Google AI Plus showed up as both $4.99 and $7.99 in two independent 2026 sources, and I could not settle it. That page now says the price is unconfirmed instead of picking the nicer-sounding one.

Same with Anthropic: Claude Opus 5.5's usage is governed by a rolling 5-hour cap plus a weekly cap, published as multiples of Pro, not absolute message counts. Anthropic does not print the numbers. So we do not either - and the page says why, instead of inventing "200 messages per 5 hours".

The rules I now apply to every tool page

The free tier is described as what you can do, not as a credit count. "Unlimited text messages since 2026-08-10, metered images, deep research and voice" is useful; "free plan available" is not.
Every number has a source URL and a fetch date, stored next to the text.
Conflicts are written down as conflicts, with the date of each figure. A directory that resolves a disagreement by guessing is just a blog post with a sort button.
Two pros and two cons, taken from the vendor's own failure notes where they exist. Google's model card, for example, is candid that small text blurs at 1K and long paragraphs go wrong.

Why bother, for a directory

Because the only thing that separates a directory from a search result is the answer to "can I afford this, and will it do the thing". The pricing split across those 4,323 entries is 2,198 free, 1,425 freemium, 700 paid - which means most of the catalogue is affordable, and the useful work is telling people where the wall actually is.

I have done 20 of 150 top pages. The remaining 130 are templated, and I would rather ship them slowly than ship them wrong.

If you want to check the argument against real listings, the free-tier filter is here - every row shows its pricing type, and the pages I rewrote carry the facts above:

https://aiverse.mindutil.com/free-ai-tools?utm_source=devto&utm_medium=social&utm_campaign=topic

Corrections welcome, especially from people who maintain these tools - if a listing is out of date, send the pricing page that beats mine.

Building a pricing-first filter for 4,300 AI tools (and what the data looks like)

Mindutil — Thu, 29 Oct 2026 02:19:23 +0000

A few weeks ago I started AIVerse, a directory of AI tools. The premise was simple: every "best AI tools" list I could find was either a paid placement farm or so stale that half the pricing was wrong. So I built the boring version instead — one that treats pricing and category data as something to be maintained, not written once.

This post is about the data side, because that is where the surprises were.

The shape of the data

Current state of the catalogue, pulled today rather than typed from memory:

Pricing model	Tools	Share
Free	2,198	50.8%
Freemium	1,425	33.0%
Paid	700	16.2%
Total	4,323	across 92 categories

Category concentration is steeper than I expected. Four categories hold a quarter of everything:

Video Generators — 294
Image Generators — 269
Productivity — 253
Developer Tools — 247

The remaining 88 categories average about 37 tools each. 708 listings carry a 2026 publish date, which tells you how fast the supply side is still growing.

One number I do not want to hide: only 614 listings have a verification level recorded. "Free" is therefore a claim taken from the vendor page, not something I confirmed by signing up. That gap is exactly the difference between a directory and a database, and it is the thing I am slowly paying down.

The bug that actually mattered

While exporting every listing to check link health, I diffed the websiteUrl field against vendor domains and found 30 rows pointing not at the vendor but at an affiliate redirect:

capcut → capcutaffiliateprogram.pxf.io/9LPy7W

pxf.io is Impact's link domain; partnerlinks.io is another one. The tracking URLs carried a referring sub-ID (?s=...), which means every "Visit website" click on those 30 pages was crediting someone else's affiliate account. Worse, the descriptions on those same rows said things like "You can use CapCut online at capcutaffiliateprogram.pxf.io" — a templated sentence that turned out to be repeated across 2,084 pages of the site.

Three fixes, in order of how much they mattered:

Reject tracking domains at every entry point. There is one shared list, imported by the crawler, the CSV importer and the public submission form. Previously each path had its own validation and they had drifted apart.
Resolve the 30 existing rows by following the redirect chain to the final vendor domain. Four needed manual judgment: one landed on a /fr locale, one self-redirected in a loop, one dead-ended on the tracker, and one pointed at a completely different product page.
Strip the templated sentence at render time, so those pages stopped showing the tracker before the underlying data was cleaned.

How the pipeline works now

Crawl the upstream catalogue.
Reject tracking domains and anything that is not a vendor-owned URL.
Strip boilerplate — four known template markers. Whatever is left under 25 words gets queued for a human instead of being rendered.
Hand-write the top 150 pages by traffic, four facts each: free tier limit, price tiers, two pros, two cons, and who it is for.
Store that hand-written copy in a git-tracked JSON overlay that takes precedence over the crawled description at render time.

Step 5 is the one I would recommend to anyone building the same thing. My first attempt wrote copy straight into the production SQLite database through an admin form. That sounds fine until you notice the deploy hook restores the live database from a backup on every push — so the copy existed only on the server that was about to be overwritten. Content in git gets a diff, a review and a rollback. Content in a production table gets none of those unless you build them yourself.

What is still broken

9 of 150 pages written. The queue orders by traffic, so this is the head of the distribution, but 94% of the hand-written coverage is missing.
No affiliate links yet. Zero of 4,323 listings have a commercial link. That is deliberate: I would rather send traffic to the vendor for free than send it to a tracker that does not pay.
The traffic numbers are inherited, not measured. They come from the source catalogue. The only numbers I trust are outbound clicks, and the total is 4. Four clicks. That is the real baseline — everything else is a guess.

Why publish this

Because the honest version is more useful than a launch post. If you are building a directory, the tracking-domain contamination and the "content in the production DB" trap will both find you, and they are easier to spot when someone else has already paid for them.

If you want to look at the result: AIVerse, free AI tools

Start with the free filter — 2,198 listings, filterable by category, with the pricing field printed on every card so you can see what the data quality actually looks like. If a listing is wrong, there is a submission form and I fix it.

1 mile is not 1.6 km: the exact factors, and where the shortcut breaks

Mindutil — Sun, 25 Oct 2026 02:34:00 +0000

Everyone learns the same trick: multiply miles by 1.6. It's fast, it's close, and for a rough sense of distance it's fine. But "close" has a number, and that number is 0.58% — which turns into almost a kilometre the moment you're planning a 100-mile drive.

This is a short reference for when you need the real number instead of the vibe.

The exact factors

These are not approximations. They are exact by definition, agreed internationally in 1959:

Conversion	Exact factor
1 mile → kilometres	1.609344
1 kilometre → miles	0.6213711922…
1 inch → centimetres	2.54
1 foot → metres	0.3048
1 pound → kilograms	0.45359237
1 US gallon → litres	3.785411784

Because the mile is defined as exactly 1609.344 metres, every mile conversion is a multiplication with a finite decimal — no rounding needed at the source. Any error you see comes from the shortcut, not the unit.

How much the shortcut costs

Here's the same set of distances through three methods: the exact factor, the common ×1.6, and the slightly better ×1.61.

Miles	Exact km	×1.6	Error (×1.6)	×1.61	Error (×1.61)
1	1.6093	1.6	−9 m	1.61	+0.7 m
5	8.0467	8.0	−47 m	8.05	+3 m
10	16.0934	16.0	−93 m	16.1	+7 m
26.2	42.1648	41.92	−245 m	42.18	+17 m
100	160.9344	160.0	−934 m	161.0	+66 m

×1.6 always undershoots. ×1.61 overshoots by about a tenth as much. Neither is wrong for a back-of-the-envelope answer — but if you're converting a distance you'll actually drive, run, or ship, the difference is real.

Three places the error matters

Running. A marathon is 42.195 km, which is 26.2188 miles — not 26.2. If you convert 26.2 miles with the exact factor you get 42.1648 km, about 30 metres short of the real distance. The 26.2 figure is a rounded nickname that became the label.

Driving. On a 100-mile leg the 1.6 shortcut is 934 metres off. That's not catastrophic, but it's enough to miss a turn in a city, and it silently accumulates across a multi-day trip.

Shipping and cooking. Pounds and kilograms have the same trap with ÷2.2. One pound is 0.45359237 kg; dividing by 2.2 gives 0.454545 kg. On a 100 lb shipment that's roughly 95 grams of drift — usually irrelevant, occasionally not.

The one rule that fixes most of it

Don't round in the middle. Convert with the exact factor, then round the final answer to the precision you actually need (two decimals for kilometres, whole grams for small weights). Rounding the factor first — 1.6093, 0.6214 — is fine; rounding it to 1.6 and then multiplying is where the error comes from.

For kilometres to miles, the reciprocal is 0.621371. The common shortcut (×0.6) is off by 3.4%, which is about six times worse than the miles-to-km shortcut people complain about.

Two related units worth knowing

Nautical mile = exactly 1,852 metres. Not the same thing, and never needs the 1.6 shortcut.
US survey mile = 1,609.3472… metres. It was retired from US federal use at the end of 2022; if you see it in an old dataset, that's why the numbers don't match.

If you just want the number without doing the arithmetic, I keep a converter with a pre-computed table (0.5 to 1,000 miles, plus the race distances) at tools.mindutil.com/en/tools/miles-to-km. It runs entirely in the browser — no upload, no account. The same table exists for cm to inches and kg to lb.

The point isn't that mental math is bad. It's that 1.6 is a label for "roughly", and it's worth knowing exactly how roughly.

Base64 encode and decode in the browser — with proper Unicode support

Mindutil — Thu, 22 Oct 2026 03:40:47 +0000

The problem with most Base64 tools

You paste text into an online Base64 encoder, hit a button, get the result. Simple enough — until you try encoding something like 你好世界 or 🎉 and the output comes back as garbage, or the site silently drops characters.

The root cause is almost always the same: the tool converts text to bytes using Latin-1 (a single-byte encoding) instead of UTF-8 (variable-length, covers all of Unicode). The result is a Base64 string that decodes correctly in ASCII contexts but produces mojibake the moment someone reads it back.

Here is how the encoding actually works, what the pitfalls are, and how to verify that any Base64 tool — online or otherwise — handles Unicode correctly.

Encoding: text → bytes → Base64

The pipeline has two steps. First, convert the string to a UTF-8 byte sequence. Second, encode those bytes as Base64.

function encodeBase64(text) {
  const bytes = new TextEncoder().encode(text);
  let binary = '';
  const chunkSize = 0x8000;
  for (let i = 0; i < bytes.length; i += chunkSize) {
    binary += String.fromCharCode(...bytes.subarray(i, i + chunkSize));
  }
  return btoa(binary);
}

TextEncoder produces a Uint8Array of UTF-8 bytes — 你好 becomes 6 bytes, 🎉 becomes 4. The loop then feeds those bytes to btoa() in chunks. The chunk size (0x8000 = 32768) keeps String.fromCharCode calls small enough to avoid call-stack limits on large inputs.

The naive one-liner many people reach for — btoa(unescape(encodeURIComponent(text))) — works but is slower and harder to reason about. TextEncoder is the modern equivalent and has been available in every browser for years.

Decoding: Base64 → bytes → text

The reverse direction has more ways to fail:

function decodeBase64(input) {
  // Strip whitespace, accept URL-safe alphabet (- and _)
  const compact = input.replace(/\s+/g, '');
  if (compact.length === 0) return { ok: true, output: '' };

  const normalized = compact.replace(/-/g, '+').replace(/_/g, '/');
  const payload = normalized.replace(/=+$/, '');

  if (!/^[A-Za-z0-9+/]*$/.test(payload)) {
    return { ok: false, error: 'Invalid characters in Base64 input' };
  }
  if (payload.length % 4 === 1) {
    return { ok: false, error: 'Invalid Base64 length' };
  }

  let binary;
  try {
    binary = atob(normalized);
  } catch {
    return { ok: false, error: 'Malformed Base64' };
  }

  const bytes = Uint8Array.from(binary, (c) => c.charCodeAt(0));
  try {
    const output = new TextDecoder('utf-8', { fatal: true }).decode(bytes);
    return { ok: true, output };
  } catch {
    return { ok: false, error: 'Decoded bytes are not valid UTF-8' };
  }
}

Three details worth calling out:

1. URL-safe Base64. The standard alphabet uses + and /, but URLs often replace those with - and _. A decoder that does not normalise first will reject valid input or produce wrong output. The replace calls above handle both alphabets transparently.

2. Padding tolerance. Base64 output is padded with = to a multiple of 4 characters. Some generators omit the padding; some add extra newlines. Stripping trailing = and whitespace before decoding avoids both failure modes.

3. The fatal: true flag. Without it, TextDecoder silently replaces invalid byte sequences with the Unicode replacement character U+FFFD. With it, a single bad byte throws, which is what you want — silent corruption is worse than a loud error.

Three quick tests for any Base64 tool

Before you trust an online encoder with real data:

Encode 你好. Correct result: 5L2g5aW9. If the tool throws instead of giving you that, it is calling btoa() on the raw string — btoa rejects anything above U+00FF with InvalidCharacterError.
Encode 🎉. Correct result: 8J+OiQ== (note the two = padding characters — a 4-byte input needs padding to reach a multiple of 4 output characters). If you get a 4-character string without padding, the tool is stripping it.
Decode 5L2g5aW9 back. Must produce 你好 exactly. Round-tripping is the real test — a tool can produce plausible-looking output and still be mapping bytes wrongly.

If a tool fails any of these, it is not handling Unicode. Full stop.

What I shipped

I put this exact pipeline behind a page with bidirectional conversion, URL-safe alphabet support, whitespace tolerance, and clear error messages when the input is not valid Base64 or does not decode to valid UTF-8: ToolStack Base64 Encoder/Decoder.

It is part of a set of 69 browser-local tools — JSON formatting, image compression, colour converters, unit conversion, calculators, QR codes — in 7 languages. No sign-up, nothing uploaded. For the Base64 tool, the entire pipeline is TextEncoder → btoa / atob → TextDecoder, exactly as above.

Disclosure, since I would check it on someone else's page: GA4 page-level analytics is enabled; text input and output never leave the tab, and there is no server-side storage of anything you paste.

https://tools.mindutil.com/

Compress images in the browser — 20 lines, zero uploads

Mindutil — Mon, 12 Oct 2026 08:54:39 +0000

The boring problem

Almost every "compress your image" site does the same thing: your file leaves the browser, gets uploaded to a bucket, is processed by something on the other end, and comes back as a download link. Fine for a wallpaper. Less fine for a screenshot with a customer's address in it, an ID photo, or a draft design that hasn't shipped.

Browsers have had a perfectly good image encoder the whole time. Here it is.

The whole thing

async function compress(file, quality = 0.8) {
  const bitmap = await createImageBitmap(file); // applies EXIF orientation

  const canvas = document.createElement('canvas');
  canvas.width = bitmap.width;
  canvas.height = bitmap.height;
  const ctx = canvas.getContext('2d');

  // JPEG has no alpha channel: transparent areas would come out black.
  ctx.fillStyle = '#ffffff';
  ctx.fillRect(0, 0, canvas.width, canvas.height);

  ctx.drawImage(bitmap, 0, 0);
  bitmap.close();

  return new Promise((resolve) =>
    canvas.toBlob(resolve, 'image/jpeg', quality)
  );
}

canvas.toBlob(blob, type, quality) is the actual encoder. The third argument only applies to lossy formats. That is the entire pipeline — decode, resample, encode — and no byte of it touches a network.

Four details that separate this from a toy

1. EXIF orientation. Phone photos carry an Orientation tag. If you decode via new Image() and drawImage, many browsers ignore it and you get a rotated output. createImageBitmap() applies the orientation when it decodes, which is why it is the entry point above instead of an <img>.

2. Transparency turns black. A Canvas starts transparent, and JPEG has no alpha, so transparent pixels encode as black. If you are converting PNG → JPEG, paint a white rectangle first, as above. If you keep PNG, be aware that quality is ignored entirely — PNG is lossless, so the "compressor" just re-encodes it.

3. Re-encoding can make files bigger. This is the one nobody warns you about. Take an already-optimised PNG, run it through a browser encoder at the same dimensions, and you frequently get a larger file. So compare sizes and keep the original when the encoder loses:

const out = await compress(file, settings.quality);
const keptOriginal = out.size >= file.size && /* same dims & format */ true;
return keptOriginal ? file : out;

A compressor that silently returns a bigger file is worse than no compressor, so the UI has to say "already optimised" instead of showing a fake −12%.

4. Canvas size limits. Browsers cap canvas dimensions, and past the limit you often get a silently blank result rather than an error. Around 16384 px on the longest edge is the safe cross-browser zone, so clamp first:

const MAX = 16384;
const largest = Math.max(width, height);
if (largest > MAX) {
  const scale = MAX / largest;
  width = Math.max(1, Math.round(width * scale));
  height = Math.max(1, Math.round(height * scale));
}

When this is the wrong tool

Honest limits:

toBlob('image/webp') support is uneven (Safari added it in 16.4), and AVIF encoding is not available this way at all. If you want the smallest file, sharp/mozjpeg/svt-av1 on a server still wins, because browser encoders are optimised for speed, not density.
Huge batches belong on a server or in a worker; doing it on the main thread freezes the UI.
HEIC input only decodes where the browser natively supports it — Safari/macOS and Windows with the HEIF extension. Chrome on Linux generally cannot. A site that claims universal HEIC conversion in the browser is shipping a WASM decoder; check the bundle size if it matters to you.

What I shipped

I put this exact pipeline behind a page — quality slider, optional resize, format choice, before/after sizes, drag-and-drop, no account: ToolStack Image Compressor.

It is part of a set of 32 browser-local tools (JSON, Base64, image compression/resizing/cropping, colour converters, unit conversion, calculators, QR codes), with the interface in 7 languages. No sign-up, and nothing is uploaded — for the image tools that is createImageBitmap + Canvas, exactly as above.

Disclosure, since I would check it on someone else's page: GA4 page-level analytics is enabled; image data and text input never leave the tab, and there is no server-side storage of anything you paste or drop.

https://tools.mindutil.com/

Compress images in the browser — 20 lines, zero uploads

Mindutil — Mon, 12 Oct 2026 07:21:08 +0000

The boring problem

Browsers have had a perfectly good image encoder the whole time. Here it is.

The whole thing

async function compress(file, quality = 0.8) {
  const bitmap = await createImageBitmap(file); // applies EXIF orientation

  const canvas = document.createElement('canvas');
  canvas.width = bitmap.width;
  canvas.height = bitmap.height;
  const ctx = canvas.getContext('2d');

  // JPEG has no alpha channel: transparent areas would come out black.
  ctx.fillStyle = '#ffffff';
  ctx.fillRect(0, 0, canvas.width, canvas.height);

  ctx.drawImage(bitmap, 0, 0);
  bitmap.close();

  return new Promise((resolve) =>
    canvas.toBlob(resolve, 'image/jpeg', quality)
  );
}

Four details that separate this from a toy

const out = await compress(file, settings.quality);
const keptOriginal = out.size >= file.size;
return keptOriginal ? file : out;

A compressor that silently returns a bigger file is worse than no compressor, so the UI has to say "already optimised" instead of showing a fake −12%.

const MAX = 16384;
const largest = Math.max(width, height);
if (largest > MAX) {
  const scale = MAX / largest;
  width = Math.max(1, Math.round(width * scale));
  height = Math.max(1, Math.round(height * scale));
}

When this is the wrong tool

Honest limits:

toBlob('image/webp') support is uneven (Safari added it in 16.4), and AVIF encoding is not available this way at all. If you want the smallest file, sharp/mozjpeg/svt-av1 on a server still wins, because browser encoders are optimised for speed, not density.
Huge batches belong on a server or in a worker; doing it on the main thread freezes the UI.
HEIC input only decodes where the browser natively supports it — Safari/macOS and Windows with the HEIF extension. Chrome on Linux generally cannot. A site that claims universal HEIC conversion in the browser is shipping a WASM decoder; check the bundle size if it matters to you.

What I shipped

I put this exact pipeline behind a page — quality slider, optional resize, format choice, before/after sizes, drag-and-drop, no account: ToolStack Image Compressor.

https://tools.mindutil.com/

Format JSON without pasting it into a random website

Mindutil — Sat, 10 Oct 2026 09:18:56 +0000

The problem

You hit an API, get a 4,000-character single line back, and need it readable. So you search "online json formatter", paste the response into the first site that loads, and press Format.

That response probably contains access tokens, customer records, internal hostnames — data you would not email to a stranger. Yet the paste box on a no-name domain has no particular reason to be more trustworthy, and nothing on the page tells you where the bytes went.

Here are three ways to get formatted JSON without it leaving your machine, plus a two-minute way to check whether any online formatter is telling the truth about it.

1. The DevTools one-liner (fastest)

Open the console and run:

JSON.stringify(JSON.parse(rawString), null, 2)

The null, 2 is the pretty-print part: second argument is a replacer, third is the indent — 2, 4, or a "\t" string. If the payload is an array of objects, console.table(JSON.parse(rawString)) is often more readable than the tree.

Zero installs, zero uploads. The catch is the failure mode: if the input is invalid, JSON.parse throws and the message is frequently useless — "Unexpected token } in JSON at position 2471". Which line? Which column? You get neither.

2. Command line

jq . < response.json     # pretty-print
jq -c . < response.json  # minify to one line

or without jq installed:

node -e 'const fs=require("fs");process.stdout.write(JSON.stringify(JSON.parse(fs.readFileSync(0,"utf8")),null,2))' < response.json

Good for files you already have on disk. Awkward for the "select 300 lines from a log, make it readable, move on" case — and jq is not on a default Windows box.

3. A purely client-side web page

This is the gap I eventually filled with ToolStack — essentially the browser version of jq, without the trust question. The JSON formatter page covers:

Format with 2 spaces / 4 spaces / tab
Minify to a single line
Validate with an error panel showing line, column and character offset, not just a raw parser message
Syntax highlighting and line numbers in both input and output, so a 3,000-line response is skimmable
Copy, download as formatted.json, and Ctrl/Cmd + Enter to format from the keyboard

One implementation detail worth knowing, because it is the difference between "useful" and "annoying": V8 does not include a position in every JSON.parse error class — {"a":} yields none at all. Recovering it means parsing the text a second time with a tolerant grammar parser (the Lezer JSON parser here) and taking the offset of the first error node. That is what lets the UI point at a line instead of shrugging.

No request is made either way: the input goes through JSON.parse inside the page, so there is nothing on the wire to sniff.

How to verify any "runs locally" claim yourself

Three checks, about two minutes:

DevTools → Network → filter on fetch/XHR. Paste a large blob, hit Format, watch for outgoing requests. Nothing should appear except analytics beacons — and note that telemetry is a separate question from your data being uploaded, so check what those payloads actually contain.
Pull the plug. With the page loaded, tick "Offline" in the Network panel (or switch off your adapter) and run the tool again. If it still works, the computation is local.
Read the client. View source and grep the bundle for fetch(, XMLHttpRequest, FormData, navigator.sendBeacon. A genuine client-side tool has its whole logic in the browser.

Disclosure for my own page, since the above is how I would audit it: GA4 page-level analytics is on; tool input and output are never captured; there is no account system and nothing is stored server-side.

If you want to look around

32 tools in total — JSON, Base64, image compression and format conversion (JPG/PNG/WebP/HEIC), color pickers and converters, unit conversion, calculators, QR codes — in 7 languages, no sign-up.

https://tools.mindutil.com/