Decode URL

decodeURIComponent (default): decodes ALL percent escapes including reserved characters (/ ? & = #). Use for query parameter values, form data, anything that’s NOT a full URL. decodeURI: preserves the reserved URL-structure characters. Use when decoding a full URL where you want %2F to STAY as / visible in the structure but you want %20 → space. Form-encoded: same as URIComponent PLUS + → space. HTML form submissions (application/x-www-form-urlencoded) encode spaces as + AND special chars as %XX. decodeURIComponent alone wouldn’t convert + back to space.

Double-encoding happens when a URL is encoded twice. %20 (the encoded space) gets encoded AGAIN: the % becomes %25, so %20 becomes %2520. Common causes: web frameworks that auto-encode-already-encoded URLs (e.g. building URLs by concatenating already-encoded parts), shell/script invocations that pass percent-signs through encoding twice, or saving URLs through a series of redirects. The tool’s hint chip appears when the decoded output still contains %XX patterns. Click “Decode again” to peel off the second layer.

Characters outside ASCII are encoded as multiple percent escapes – one per byte. é (U+00E9) in UTF-8 is bytes 0xC3 0xA9 → encoded as %C3%A9. The browser’s native decodeURIComponent handles UTF-8 reassembly automatically. Examples: ☕ = %E2%98%95 (3 bytes), 🌍 = %F0%9F%8C%8D (4 bytes, requires surrogate pair in JavaScript strings). All Unicode supported.

Throws URIError: URI malformed. The tool catches this and shows “Malformed URL encoding”. In batch mode, only the invalid line is marked with an error – other valid lines still decode. The native API requires complete 2-digit hex after each %; %2 (one digit) and %2Z (non-hex) both fail.

Uses the browser’s native URL constructor. Splits the URL into: protocol (https:), host (with port if non-default), hostname, port (or “(default)” for 80/443/etc.), pathname, search (the raw ?... part), hash (the #... fragment), origin. Plus query parameters as a key-value list (with values already decoded). Useful for debugging APIs and reading malformed deep-links.

Historical. In application/x-www-form-urlencoded (HTML form submissions), spaces are encoded as +. In general URLs (RFC 3986), spaces are encoded as %20 and + is literal. So ?q=hello+world on a typical form-submitted query means “hello world”, but ?q=hello+world as a manually-built URL likely means literal hello+world. There’s no automatic way to know which – that’s why the mode toggle exists.

Split by newlines. Each line decoded independently – invalid lines get an error marker like # Line 3 "...": ERROR - Malformed URL encoding while valid lines decode normally. Stats card shows successes vs errors. URL parts parser only activates for single-URL input (multi-URL input shows a note).

The tool decodes them faithfully – %00 becomes \x00 (null character), %0A becomes a literal newline (which appears in the output), etc. Be aware that null bytes and certain control chars may break downstream tools you paste into. If you see odd output, check for these. The native API doesn’t reject them (unlike some hardened parsers).

Yes. URL decoding uses native browser APIs (decodeURIComponent, decodeURI, URL constructor). Your URLs never leave your device. Sensitive query params, API keys, session tokens, OAuth state – all stay in your browser.