URL Encoder / Decoder

URLs can only safely contain a limited set of characters — spaces, ampersands and other special symbols need to be percent-encoded to travel through a URL correctly without being misread as part of its structure.

Inputs

Result

search%3Fq%3Dcalculator%20hub

How the url encoder / decoder works

Encoding replaces characters outside the URL-safe set with a '%' followed by their hex byte value — a space becomes %20, for instance.

Decoding reverses this, converting percent-encoded sequences back to their original characters.

Worked example: encoding 'search?q=calculator hub'

  1. Encoded: search%3Fq%3Dcalculator%20hub.
  2. The '?' becomes %3F, '=' becomes %3D, and the space becomes %20 — each because those characters have special structural meaning in a URL and would otherwise be misinterpreted if left as-is within a value.

Common mistakes to avoid

Encoding an entire URL, including its structural characters like '://' and the domain

Structural URL characters like the scheme separator and path slashes need to remain unencoded for the URL to work as a URL — typically only the specific value being inserted into a query parameter or path segment should be encoded, not the whole URL string.

Double-encoding a value that's already encoded

Running an already-encoded string through encoding again turns each '%' into '%25', producing a mangled double-encoded result that won't decode back to the original text correctly in one pass.

Frequently asked questions

Why can't URLs just contain spaces directly?

Spaces (and several other characters) have historically caused ambiguity or breakage in URL parsing across different systems — percent-encoding provides an unambiguous, universally supported way to represent any character safely within a URL.

What does %20 specifically represent?

20 is the hexadecimal ASCII code for the space character (32 in decimal) — percent-encoding always uses the hex byte value of the character being encoded.

Is percent-encoding the same as Base64 encoding?

No — they're different techniques for different purposes. Percent-encoding makes text safe specifically within a URL's character constraints; Base64 encodes arbitrary binary data into printable text for general safe transmission, unrelated to URL structure specifically.

Why might I need to encode a query parameter value but not the whole URL?

Only the actual data value (like a search term containing spaces or special characters) typically needs encoding — the URL's own structural parts (scheme, domain, path separators, parameter names) should stay as literal, unencoded characters for the URL to remain valid.

Related calculators