Testers & Validators

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. The third header in this group is the one with the most silent failures: a Content-Security-Policy accepts a keyword without quotes as a hostname and a typo in a directive name without a word. The CSP analyzer reads the policy out of the raw header, the nginx or Apache line or a meta tag, names every weakness with its fix, and writes the finished header back for the server you run.

A HAR export is the whole session in one file, and that is its problem twice over: it is too big to read by hand and it contains every cookie and token that was sent. The analyzer renders the waterfall with all timing phases, computes compression and cache findings, names the slow TTFBs and redirect chains, and has a sanitizer that strips the credentials before the file goes into a ticket.

robots.txt looks trivial and is parsed by rules almost nobody has read. Longest match wins, not first match, an Allow can beat a Disallow, and every bot picks its own user-agent group. The tester runs your URLs against the file under the RFC 9309 rules for Googlebot, Bingbot, GPTBot, ClaudeBot or any agent you type, and every verdict names the line that decided it.

IBANs, card numbers and VAT IDs all carry their own proof of correctness, which means a typo is catchable offline, without asking any bank or tax office. The IBAN validator knows the structure of all 89 registry countries and points at the position that breaks a number, the VAT checker runs the national check-digit algorithm for each EU state, and the Luhn checker shows the whole mod 10 calculation instead of a bare verdict.

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.

A JSON parser stops at the first error, and a file that was hand-edited, pasted from a chat window or glued together from logs rarely has only one. The validator reads on after each failure: every syntax error is listed in one pass with line, column, code frame and the fix, and one click applies all of them without touching your formatting. It also reports what JSON.parse accepts without a word, duplicate keys that silently overwrite each other, integers that JavaScript rounds, lone surrogates, a __proto__ key, and it knows the difference between JSON, JSONC, JSON5 and NDJSON instead of calling all three of the others invalid.

A diff that marks two identical-looking lines as changed is right, and no diff viewer tells you why. The line ending is CRLF on one side, a space is a non-breaking space, a quote is curly, an accent is stored as two code points. The text diff shows the two texts side by side or as a unified patch with word-level highlights, takes the git flags under their own names (--ignore-whitespace, --ignore-eol, --context), and runs every changed line pair through the normalizations that make such lines equal, so the report says CRLF, NBSP or NFD with a line number instead of leaving you to compare glyphs. When nothing visible changed at all, it says that in one sentence. The semantic similarity checker asks the other question about two texts: not which characters differ, but whether they mean the same thing. A 23 MB sentence-embedding model runs in the tab, the cosine similarity appears as you type next to the plain word overlap, both vectors are drawn out, and a pasted list comes back with its near-duplicates paired up.

Checking things before they reach production