JSONFormatting.org

Encode / Decode

URL Encoder, Decoder & Query String Parser

Encode or decode percent-encoded text, or break a full URL down into readable parts.

Home › Tools › URL Encoder/Decoder
Output
Output will appear here

URL encode, decode, and parse query strings

Percent-encoding (also called URL encoding) makes text safe to place inside a URL by replacing reserved and non-ASCII characters with %XX sequences. This tool covers three common needs: encoding a value for use in a query string, decoding a percent-encoded value back to readable text, and breaking a full URL apart into its protocol, host, path, and query parameters.

Encode vs. decode vs. parse

  • Encode: Converts spaces, &, ?, #, and other special/non-ASCII characters into percent-encoded form, using JavaScript's encodeURIComponent rules — the correct choice for encoding an individual query parameter value.
  • Decode: Reverses percent-encoding back to the original text.
  • Parse URL & Query String: Splits a full URL into protocol, host, port, path, and each query parameter as a readable key/value pair.

Typical use cases

  • Building query strings by hand: Safely encode a value (like a search term with spaces) before appending it to a URL.
  • Debugging redirects: Decode a percent-encoded redirect_uri or callback URL to see the real destination.
  • Reading tracking/UTM parameters: Product managers can paste a marketing link to instantly see every UTM parameter as a clean table.
  • API debugging: Break down a long request URL to check exactly which parameters were sent.

Frequently Asked Questions

This tool uses encodeURIComponent rules, appropriate for encoding an individual value (like a query parameter) that may itself contain &, ?, or /. Encoding an entire URL (which has some characters that must stay unescaped, like : and / in the path) is a different, less common operation.
A space becomes %20 under standard percent-encoding rules. Some older systems (like HTML form submissions) instead use + for spaces in the query string — both are valid depending on context.
Add https:// to the front if your URL doesn't include one; browsers' URL parsers require a scheme to parse correctly.
No. Everything runs locally using your browser's built-in URL and encoding APIs.