Media tools are next. Everything ships the same way: it runs in your tab, or it does not ship.
Testers & Validators
Tools that answer why something behaves differently from how it looks. A character you cannot see, a cookie the browser threw away without saying so, a YAML value that means two things, a regex that is fine until someone sends it the wrong string. Everything is analysed in your browser, which matters when the thing you are debugging is a live session token.
9 tools. All in your browser.
Nothing you paste is uploaded, and once a tool has loaded it keeps working offline. Free, no signup.
Text and characters
2 tools
Text that arrives through a chat window, a PDF or a word processor is never plain text. It carries curly quotes, non-breaking spaces, soft hyphens and the occasional zero-width space, and every one of those breaks something further down: a CSV import, a code block, a password field, a diff. The character detector names each one, says where it sits and hands back a cleaned version, and it only flags lookalike letters inside words that really mix alphabets, so Russian or Greek text does not drown the report in noise. The AI text detector answers the other question people have about pasted text: it scores the measurable writing patterns of chat-model output, highlights every match in place, and is upfront that a style score is evidence to weigh, never proof of authorship.
Two headers cause a large share of the bugs that look like backend problems and are not. A Set-Cookie line that a browser silently refuses to store, and a Cache-Control header whose directives cancel each other out. Both tools read the raw header you copied out of devtools and tell you what a browser and a CDN will really do with it, including the combinations that are rejected without any error.
A YAML file and a .gitignore have the same failure mode: they are accepted, they do something, and it is not what you wrote. YAML resolves NO to a boolean, 0644 to 420 and 1.10 to 1.1, and which of those you get depends on whether the parser follows the 1.1 or the 1.2 rules. A .gitignore rule loses to a later line, or sits behind an excluded directory where git never reads it. Both tools show the resolved meaning next to what you typed, and the gitignore tester matches paths the same way git does, down to the output format of check-ignore.
A cron expression is five fields that everyone reads slowly and nobody reads reliably, and if it came from a Java project it is six fields whose weekday numbers mean something else. The parser reads crontab, Spring and Quartz natively, seconds, ?, L, W and # included: the expression sits front and centre, its plain-English meaning underneath, one card per field, then the next runs in your timezone and UTC. The traps that survive code review are called out, from day fields that OR in a crontab but AND in Spring to the job parked in the hour DST deletes and the % sign that quietly truncates the command.
A slow query rarely announces why it is slow. The database happily runs WHERE YEAR(created_at) = 2024 as a full scan, uses none of your indexes because the composite has its columns in the wrong order, and returns zero rows from a NOT IN the moment the subquery picks up a NULL. The optimizer parses the query and your CREATE TABLE / CREATE INDEX statements together, matches every filter and join column against the actual indexes, and answers with rewrites and ready-to-run CREATE INDEX statements instead of a lecture. It is static analysis and says so: table sizes and row counts stay the business of EXPLAIN ANALYZE, but the structural mistakes are all catchable before a query ever reaches a database.
One regex is enough to take a server offline, and it looks like every other regex in the file. The checker finds the repetitions that can consume the same characters in more than one way, builds the input that forces the engine through all of them, and then runs it: instead of a warning you get a growth curve and the number of characters at which the match costs a full second of CPU. It also separates the patterns that are genuinely exploitable from the ones that are only ambiguous, which is the distinction warning-only linters skip.
The parsers ship with the page, so a tool keeps working after you go offline.
Instant, as you type
Every tool runs the moment you type. No run button, no waiting, nothing to install.
Free forever, no signup
No account, no paywall, no trial that expires. All 70+ tools, free for everyone.
Validation is mostly about the invisible part
Every tool in this category exists because something failed quietly. Browsers do not report a rejected cookie to your code, caches do not tell you that two directives contradict, and no editor shows you a character with no width. The bug is real, the evidence is not on screen, and you end up guessing.
So these tools all work the same way: they take the raw thing you already have, the header line or the string that failed, and print what a browser actually does with it.
Which is why none of it is uploaded
A Set-Cookie header from a real response contains a working session. A string that fails a comparison is often a password or an API key. Pasting either into a server-side validator hands over a live credential that then sits in someone's access log. Everything here runs as JavaScript in your tab and keeps working after you disconnect.
Checking things before they reach production
What should I never paste into an online checker?
Anything that is still valid: live access tokens, session cookies, private keys, connection strings, and personal data you are responsible for. The question is not whether a particular site is trustworthy but whether the value survives the visit, so if a token has to be checked, use one you can revoke afterwards, and revoke it. For everything else the useful test is mechanical: open the network tab, do the thing, and see whether a request leaves at all.
Which checks belong in a pre-commit hook and which belong in CI?
Pre-commit gets what is fast and local: formatting, lint on changed files, secret scanning, a schema check on config files. CI gets what is slow, needs the whole repository, or must not be skippable, since any developer can pass --no-verify. The trap worth avoiding is running the same slow suite in both, which trains people to bypass the hook. Anything that has to hold, gate it in CI and treat the hook as a convenience.
Why does the same input behave differently in two libraries?
Because most of these formats are specified loosely enough that conforming implementations disagree. YAML 1.1 and 1.2 resolve unquoted scalars differently, so PyYAML and the JS yaml package read the same file into different values. Regex flavours differ on lookbehind, \w and inline flags. Cookie and cache header parsing differs between browsers and proxies. When two tools disagree, the useful question is which specification version each one implements, not which one is broken.
How do I test a rule against real paths without committing anything?
Use the dry-run mode the tool already has: git check-ignore -v --no-index prints which pattern matches a path, git apply --check tests a patch without touching the tree, nginx -t validates a config before reload, and most linters take a --dry-run or -n flag. For rules that live in a file a service fetches, such as robots.txt or a CSP, the equivalent is evaluating a candidate file locally against the URLs you care about, before it is published anywhere.
The bug only appears in production. How do I narrow it down?
Compare the exact bytes rather than the rendered result, because most of these bugs are invisible on screen: a character that renders as nothing, a header that a proxy rewrote, a whitespace difference that changes a hash. Capture the real request and response (a HAR export or curl -v), diff it against the same request from your machine, and check length before content, since a length mismatch localises the problem faster than reading either version.