URL Encode & Decode Online

Safely encode special characters for URLs or decode percent-encoded text to inspect parameters—useful for OAuth callbacks, APIs, and debugging links.

What is URL encoding (percent-encoding)?

URL encoding—formally percent-encoding—replaces reserved or non-ASCII characters in URI components with escape sequences like %20 for space or %E2%82%B9 for the rupee symbol. Browsers, servers, and HTTP clients use encoding so parsers do not confuse user data with structural characters such as ?, &, =, /, or #. CompareStack’s URL encode and decode tool lets you convert plain text to a transport-safe form and back again without writing a one-off script in every language you work with.

Encoding is reversible and public—anyone can decode a percent-encoded string. It is not encryption. Treat encoded API keys or session tokens in query strings the same as plaintext in logs and browser history.

How to encode or decode URLs on CompareStack

  1. Paste a full URL, a query value, or a path segment into the input field.
  2. Click Encode to produce percent-encoded output safe for query parameters or path segments.
  3. Click Decode to read an encoded string as plain text—useful when logs print escaped values.
  4. Copy the result into your application, Postman collection, or documentation.
  5. Encode once at the layer that builds URLs; avoid passing already-encoded strings through encode again.

Which characters must be encoded?

In query parameter values, encode spaces, ampersands, equals signs, plus signs, hash marks, and non-ASCII Unicode when they are part of the data—not when they separate parameters. Slashes inside a path segment may need encoding depending on your framework; some libraries encode automatically when you call encodeURIComponent in JavaScript or equivalent helpers in Python, Go, and Java.

Fragment identifiers (the part after #) are handled differently in browsers: encoding rules for fragments are looser, but server-side redirects should still treat fragments carefully when building callback URLs for OAuth and payments.

Encode once, decode once

Double-encoding is the most common integration bug: passing an already-encoded value through encode again turns %20 into %2520, breaking links and invalidating HMAC signatures on payment or OAuth callbacks. Decode at a single trusted boundary—usually server-side—after the request arrives, then work with plain text internally.

HTML forms submitted as application/x-www-form-urlencoded treat + as space in the body. Path segments should use explicit %20 rather than assuming plus-sign semantics. Mixed conventions between client libraries cause subtle production bugs that only appear for certain locales or campaign names.

Real-world debugging scenarios

OAuth and payment callbacks. Signature algorithms require an exact byte sequence. When validation fails, compare encoded and decoded forms side by side and log the canonical string your verifier uses—not only the pretty decoded view. A single unencoded space or an extra encode pass invalidates the hash even when humans see identical text.

Marketing and analytics UTM links. Campaign names with spaces, ampersands, or non-Latin characters must have parameter values encoded, not the entire URL blindly. Encode each value, then assemble the query string with unencoded & separators between parameters.

Deep links in mobile apps. Custom URL schemes and universal links often embed JSON or tokens in query strings. Test round-trip encode/decode in CompareStack before shipping to catch charset and double-encoding issues early.

Legacy systems and log analysis. Mainframe or ERP exports sometimes percent-encode filenames in download URLs. Decode log lines to read the original path, then compare against a known-good URL using our Text Compare tool when regressions span multiple parameters.

URL encoding versus Base64 and JSON

URL encoding makes text safe inside URI components. Base64 represents binary or arbitrary bytes as ASCII text—common in Authorization headers and JSON fields, not typically for entire URLs. JSON bodies use their own escaping rules for strings. Pick the right transform: encode query values here, format JSON with our JSON Formatter, and inspect Basic Auth blobs with Base64 Encode / Decode.

Limitations and expectations

  • This tool processes the string you paste—it does not validate that a full URL is well-formed for every RFC edge case.
  • Internationalized domain names (IDN) may appear as punycode in some logs; decode percent-sequences in paths separately from hostname handling.
  • Very long encoded strings paste fine, but split extremely large blobs when comparing in tickets for readability.
  • Do not paste live passwords or production secrets unless your organization permits online utilities.

Security reminder

Encoding does not hide data. Secrets belong in POST bodies, headers, or secure cookies—not query strings visible in referrer headers and server access logs. Use HTTPS for all production traffic. Read our Privacy Policy for how pasted input is handled during your session.

Related reading

URL encoding in production integrations

Encode each query parameter value separately, then join with unencoded ampersands—avoid encoding the entire URL in one pass.

When OAuth or payment signatures fail, log and compare the canonical encoded byte sequence your verifier expects, not only the decoded view.

Pair URL encode/decode with Text Compare when debugging multi-parameter callback regressions across environments.

Tool FAQ

When should I encode a URL?

Encode query parameter values that contain spaces, ampersands, or non-ASCII characters before appending them to a URL.

Can encoding break OAuth signatures?

Yes. Signed URLs require exact byte sequences. Compare encoded and decoded forms carefully when debugging callbacks.

What is double-encoding?

Encoding an already-encoded string turns %20 into %2520 and breaks links. Encode once at the URL builder layer.

Is URL encoding the same as encryption?

No. Percent-encoding is reversible and not secret. Do not put passwords in query strings.