URL encoding validator
A URL that a parser rejects and a URL that quietly means something different are two separate problems, and both come from bad escaping. This checks a URL — or a whole list — for every escaping fault worth knowing about, says which are fatal and which are merely wrong, and gives you a repaired version to compare against.
Findings
Summary
How to use
- Paste the URL, or the whole list of URLs you want checked.
- Read the Findings table. Rows are colour-coded by level: error means something will break, warn means it probably means something other than you intended, info means it works but is not canonical.
- Each row's last column says what to do about it, not just what is wrong.
- Compare the Repaired output against your input. It strips control characters, un-escapes HTML entities, and encodes what is still illegal — but it is a starting point, not a guarantee, because some faults have more than one plausible fix.
The nine faults it looks for
Incomplete escape — a % not followed by two hex digits. ?q=100% and %zz both make decodeURIComponent throw, so the request fails before your code sees it. A literal percent sign must be %25.
Raw space and control characters — never legal unescaped. A trailing CR from a Windows text file is the single most common invisible cause of "the URL works when I retype it".
Unsafe characters — < > " { } | \ ^ ` [ ] outside the authority. Browsers often encode them for you, which means the URL works in a browser and fails in curl, your backend, and every log parser.
Double encoding — the presence of %25 followed by hex. Diagnose it properly with the double URL decoder, which shows each layer.
%uXXXX — a Microsoft JScript extension that was never part of any URL standard. Modern servers reject it.
HTML entities — & where a plain & belongs, meaning the URL was copied out of HTML source. The entity fixer handles this properly.
Mixed-case escapes — %3a and %3A mean the same byte, but RFC 3986 prefers uppercase, and a cache keyed on the raw string treats them as two URLs.
Over-escaped unreserved characters — %2D for -, %7E for ~. Legal, but it changes the canonical form, so two URLs that should be identical are not.
A query that will not decode — the escapes are syntactically valid but not valid UTF-8. Usually a truncated multi-byte sequence, or a legacy charset; the legacy charset decoder will tell you which.
FAQ
Why is the repaired URL sometimes different from what I expected?
Because repair has to guess. A raw space could be %20 or + depending on where it sits; a stray % could be a literal percent sign or a truncated escape. The repaired output takes the safe reading — encode, do not decode — and it is there for comparison rather than blind use.
My URL is flagged but works fine in Chrome.
Browsers are deliberately forgiving: they encode illegal characters silently before sending the request. Nothing else in your stack is that generous. A URL that only works in a browser is a URL that will fail the moment it reaches a script, a webhook or a proxy.
Are info-level findings worth fixing?
Only where the canonical form matters — cache keys, signed URLs, deduplication and canonical tags. For a link you are about to paste into an email, they are noise.
Can I see the exact bytes instead?
Yes — the byte inspector lays the URL out one character per row with codepoints and UTF-8 bytes, which is the fastest way to identify an invisible character.