URL Encode / Decode

What URL encoding (percent-encoding) means

A URL can safely carry a limited ASCII set. Everything else — spaces, non-ASCII letters, reserved symbols — is written as percent-encoding: % plus two hex digits (a UTF-8 byte or other, depending on context). Example: space → %20, é in UTF-8 → %C3%A9.

This calculator follows semantics close to JavaScript encodeURIComponent / decodeURIComponent: it encodes characters that are unsafe in a URI component (parameter value, path segment), and decodes %HH sequences back to text.

Which characters usually need encoding

• URI reserved: :/?#[]@!$&'()*+,;= — inside a parameter value they often must be encoded or they change URL structure.
• Spaces and controls — always encode in query/path components.
• Unicode (accents, €, emoji) — as UTF-8 percent-encoded byte sequences.
• Typically safe in encodeURIComponent: A–Z a–z, digits, - _ . ! ~ * ' ( ) — details vary by API; do not assume identity with encodeURI.

Space: %20 vs plus (+)

• %20 — universal percent-encoding for space (path, query, most APIs).
• + — in application/x-www-form-urlencoded (classic HTML forms), space is often a plus in the query string.
• encodeURIComponent('a b') → a%20b (not plus). Treating bare + as space is a form-encoding rule, not plain URI-component decoding.

If an API expects form-urlencoded, read the docs — mixing %20 and + is a common integration bug.

Encoding vs decoding

• Encode — user text / parameter → safe URL fragment.
• Decode — %HH from logs, OAuth callbacks, copy-paste → readable text.
• Encoding is not encryption: anyone can decode it. It does not protect secrets.
• Invalid % sequences (e.g. %ZZ, truncated %C3) fail decoding — the calculator reports that.

Path vs query string

• Query (?q=...) — encode each value with a component encoder, then join pairs with & / =.
• Path — keep structural slashes; encode odd characters inside segments. encodeURI (whole URL) preserves more reserved characters than encodeURIComponent.
• Fragment (#...) — do not encode the opening #; encode fragment content as your app requires.

Bad practice: run encodeURIComponent on a full https:// URL for the address bar — you get a useless blob (unless you intentionally pass a URL as a parameter value).

Common mistakes and double-encoding

• Double-encode: a b → a%20b → again → a%2520b. Symptom in logs: %25.
• Encoding an already-built query including & — breaks parameter structure.
• Decoding “just in case” repeatedly — can corrupt data that legally contains %.
• Confusing Base64 with percent-encoding — different alphabets and purposes.
• Copying UI pluses into a context that expects %20.

Worked examples

• hello world → hello%20world
• a&b=c (as a value) → a%26b%3Dc
• café → caf%C3%A9 (UTF-8)
• 100% sure → 100%25%20sure (% must be encoded too)
• Decode a%2520b once → a%20b; twice → a b (undoing double-encode on purpose)

Paste your own string into the form — copy the result into an HTTP request or API docs.

Safe URL-building workflow

• Build the base URL with fixed parts (https://api.example.com/v1/search).
• Encode each parameter value separately (this calculator / encodeURIComponent).
• Join ?k= + encoded + & + more pairs — do not encode the finished query a second time.
• When debugging: if logs show %2520, decode once and find which layer over-encodes (frontend, gateway, SDK).
• Regression tests: space, &, %, emoji, empty string, already-encoded input.

Full query example: search phrase shoes & bags → value shoes%20%26%20bags → URL .../search?q=shoes%20%26%20bags.