DEV Community: toolsvale

I audited 12 free SEO tools. Here's what they all get wrong.

toolsvale — Thu, 20 Aug 2026 22:01:50 +0000

Last week I needed to audit a client site — check broken links, verify schema, sanity-check a sitemap, spot-check indexing on 40 URLs. Nothing exotic. I opened Google, typed the obvious queries, and clicked whatever ranked.

Four hours later I had my report, but I also had a very long list of ways free SEO tools are quietly broken. Not "missing features" broken — actively misleading broken. This post is that list, because I ended up building ToolsVale around the fixes and I think the pattern is worth writing down whether you build tools or just use them.

The setup

Twelve tools total, spread across the four jobs above: broken link checkers, schema validators, sitemap generators, indexing checkers. For each one I gave the same input a real site would give: 500 URLs for the link checker, a live JSON-LD block for the schema tool, an existing sitemap for the generator, 40 URLs for the indexing check.

I noted every single thing that broke, gated, or gave me an answer I couldn't trust. I'm not naming names — this is about pattern, not takedown — but if you've used a free SEO tool recently you've hit at least four of these.

The 8 patterns

1. The sign-up wall at result 5

Every free broken link checker I tried let me check 3–10 URLs before demanding an account "to continue." Not for advanced features. To see result #6.

The tools that do this are betting you're too invested to bounce. Sometimes they're right. Mostly you close the tab and try the next result.

The fix: no auth. If the crawl runs in the browser (fetch + concurrent workers), there's no server cost to gate. Even server-side, a 500-URL crawl is measured in cents, not dollars.

2. Redirect chains flattened to final destination

Nine of the twelve link checkers showed only the final URL in a redirect chain. So a URL that goes /page → /page/ → /new-page/ → 404 shows up as "404" with no indication of the two hops in between.

This matters because the redirect chain itself is the SEO problem. Each hop leaks link equity. A tool that hides the chain is hiding the actual work you need to do.

The fix: show every hop, every status code, every URL, in order. Half a day of dev work.

3. "Broken link" without the source page

Most broken link tools tell you the URL is broken. Almost none tell you which page on your site is still linking to it. So you have a 404, but you don't know what to edit to remove the link.

If you don't have the source, you can't fix the cause — only the symptom (by 301-redirecting the broken URL somewhere, which just adds a redirect chain, see problem #2).

The fix: during the crawl, store the referrer for every URL discovered. Trivially cheap. Nobody does it.

4. Schema validators that accept garbage

I fed a JSON-LD block to five free schema validators. Three of them said "valid" for a block that was missing required properties (@context, @type, and — in one case — a mandatory datePublished for Article schema).

They're technically running through a JSON linter, not a schema.org validator. But they're called "schema validators" and users assume the check means something.

Google's own Rich Results Test catches these. Free third-party tools mostly don't.

5. Sitemap generators that ignore rules

The sitemap.xml spec has real constraints: 50MB max file size, 50,000 URLs max per file, index files needed above that. Three of the four sitemap generators I tried produced a single flat file for a 65,000-URL input, in violation of the spec, and Google will reject it on ingestion.

The fix: split into sitemap-1.xml, sitemap-2.xml, etc., with an index. It's a while-loop.

6. Cached results shown as live

Two of the three indexing checkers I tested returned results in <100ms for a URL that had been published five minutes earlier. That's not a live check — that's a cached snapshot from days or weeks ago.

The tools don't say this. They just show a green "indexed" checkmark for a URL that Google has never seen.

The fix: either do a real live check (site: query, respecting rate limits), or clearly label the data source and age. Users can handle "cached from 3 days ago." They can't handle "green tick, in reality Google 404's your URL."

7. Robots.txt as an afterthought

Half the free crawlers I tested happily crawled /wp-admin/, /checkout/, /cart/, and anything else robots.txt would have disallowed a well-behaved crawler from touching. Some of these paths return sensitive data if you're logged in — which the tool won't be, but the point is a tool that doesn't respect robots.txt isn't a serious tool.

The fix: fetch and parse robots.txt before crawl, honor Disallow for User-agent: * at minimum. Small library away.

8. Hreflang tools without x-default

Free hreflang generators universally forget the x-default value. x-default is what Google uses when the visitor's language doesn't match any of the declared alternates. Skip it and you're telling Google "if the user speaks Portuguese and my site is only in English/Spanish/French, I have no opinion" — which becomes a soft-signal ranking issue.

Every generator I tried was missing this. Fix: add one more form field with a plain-English label ("Which language should show when nothing else matches?"). Ten minutes of work.

Why is it like this?

I don't think most of these SEO tools ship broken defaults out of malice. I think they ship as MVPs — a wrapper around a Python script or the Google Custom Search API, monetized with ads, then forgotten. The gaps aren't bugs to fix, they're features that would eat the paid tier or expose that the "free" checker is actually a lead magnet.

Which means the space is enormous, the incumbents are entrenched by SEO not quality (yes, SEO tools ranking on SEO — the irony writes itself), and it's genuinely open to anyone who ships a version that doesn't have these problems.

What I built

I ended up building ToolsVale — free browser-based tools for images, PDFs, data and SEO, currently 38 of them. The rule is: before any tool goes live, we run the same input through the popular alternatives and note where the output breaks. Those notes become the spec. Every claim on a tool page comes with a test you can run in under a minute.

A few examples for anyone curious:

bulk URL status code checker — 500 URLs, full redirect chains shown, soft-404 detection, response times, and headers. Fixes problems #1 and #2 above.
broken link checker — bulk broken link scanner that stores the source page for every broken URL, not just the destination. Fixes problem #3.
trailing slash checker — finds URLs redirecting only because of a missing or extra slash, and traces back to the source page still linking to the wrong version. This is problem #3 applied to a very specific SEO gotcha.
schema markup generator — outputs schema that actually passes Google's Rich Results Test, not just JSON lint.
hreflang generator — includes x-default by default because that's the correct answer.

Most tools run entirely in the browser. The ones that need a server (like bulk URL checking, which can't be done purely client-side due to CORS) say so on the tool card with a stated deletion window.

The takeaway if you're not building tools

If you're just picking an SEO tool for a task, three things to check before you rely on any result:

Give it a URL you know has a redirect chain (any http:// URL that ends up on https:// with a trailing slash works). Does it show all hops, or only the final destination?
Give the schema validator a JSON-LD block with a deliberately missing required field. Does it catch it, or does it happily pass?
Check whether the indexing checker returns instantly (<200ms). If yes, it's cached data, not a live check.

If you're building one, the good news is the bar is astonishingly low. Almost every "premium" feature these sites gate is a while-loop, a spec-compliance check, or storing one extra field during crawl.

The gap isn't technical. It's positioning. Anyone who ships the honest version wins.

Full tool set at toolsvale.com — free, no accounts, no watermarks, most run in your browser. Open source components at github.com/toolsvalewebsite.

If you build in this space and want to compare notes on the browser-only approach, I'm on X @toolsvale_web.

I created "Absolute Best" Broken link checker

toolsvale — Wed, 19 Aug 2026 21:14:32 +0000

Quick Website Check

Broken links are easy to miss on larger websites.
A 404 can come from deleted pages, changed URLs, bad redirects, or external sites going offline.
I’ve been using a simple free tool to crawl a website and find broken links.
It also shows exactly which page contains the broken link, not just the dead URL.
It supports internal + external links and lets you export the results.
No signup required.

🔗 https://toolsvale.com/broken-link-checker/

Useful for developers, SEO audits, migrations, and website maintenance.

How I Built an Image Converter That Never Touches a Server

toolsvale — Fri, 14 Aug 2026 07:15:39 +0000

How I Built an Image Converter That Never Touches a Server

Home - ToolsVale

toolsvale.com

Most "free online image converter" sites work the same way under the hood: your file gets POSTed to an endpoint, a server does the actual conversion, and you get a download link back. That's normal and fine for a lot of use cases — but it means every file you convert briefly exists on infrastructure you don't control, and it means the tool needs a backend, storage, cleanup jobs, and rate limits just to exist.

I wanted to see if I could skip all of that and do the conversion entirely in the browser instead. Turns out modern browser APIs make this pretty viable. Here's roughly how it works.

The core idea: Canvas as a conversion engine

The browser's element can decode most image formats it can display, and re-encode them via canvas.toBlob() or canvas.toDataURL() with a different MIME type. So a JPG → WebP conversion is roughly:

async function convertImage(file, outputType = 'image/webp', quality = 0.8) {
const bitmap = await createImageBitmap(file);
const canvas = new OffscreenCanvas(bitmap.width, bitmap.height);
const ctx = canvas.getContext('2d');
ctx.drawImage(bitmap, 0, 0);
const blob = await canvas.convertToBlob({ type: outputType, quality });
return blob;
}

createImageBitmap handles the decode off the main thread, OffscreenCanvas lets you do this inside a Web Worker (important — you don't want to block the UI on a 40-image batch), and convertToBlob handles re-encoding. No network request anywhere in that flow.

Where it gets harder: formats the browser can't natively decode

Canvas only helps for formats the browser already knows how to render. HEIC is the obvious problem — no mainstream browser decodes HEIC natively, since it's patent-encumbered and Apple-specific. For that, you need a WASM-compiled decoder (libheif compiled to WASM works) running client-side, which decodes HEIC into raw pixel data the canvas can then take over from. Same category of problem for AVIF on older browser versions, though support there is improving fast.

The general pattern: whatever the browser can decode natively, let it. Whatever it can't, ship a WASM decoder for. This keeps the bundle smaller than compiling everything to WASM, since you're only covering the gaps.

The trade-offs, honestly
Performance is your user's device, not yours. A batch of 200 large images on a low-end laptop will be slow. There's no way around this — you're trading server cost for user CPU time. For most day-to-day batch sizes it's a non-issue, but it's not free.
No persistence. Nothing's stored anywhere, which is the whole point, but it also means there's no "history" or account-based re-download. Close the tab before saving and it's gone.
Web Workers are non-negotiable for batches. Running conversion on the main thread freezes the UI on anything more than a couple of files. OffscreenCanvas + Workers is what makes multi-file drag-and-drop feel responsive instead of janky.
Memory matters more than you'd think. Holding decoded bitmaps for dozens of large images in memory simultaneously adds up fast — worth converting and releasing one at a time rather than decoding everything upfront.
Why bother, when server-side is simpler to build

Two reasons I found compelling enough to go this route:

No file-size or file-count caps to justify. Server-side tools cap free usage because storage and bandwidth cost money. Client-side has no such constraint — the only limit is the user's own machine.
It's verifiable, not just claimed. "We don't store your files" is a common claim on converter sites, but users can't check it. With client-side processing, anyone can open the network tab or go offline mid-conversion and see for themselves that nothing left the device.

I ended up building this out into a small set of tools — ToolsVale — covering the common image conversion pairs (JPG/PNG/HEIC/AVIF ↔ WebP), image-to-PDF, and compression, all running on this pattern.

Curious if anyone else here has shipped something similar — particularly interested in how others have handled HEIC decode performance, since that's been the trickiest part so far.