URL Encode/Decode
Encode or decode special characters in a URL string.
💡 Common Use Cases
- Encode query parameters for API requests
- Fix special characters in URL strings
- Decode obfuscated or encoded URLs
- Prepare text for safe embedding in hyperlinks
URL encode and decode any string — instantly, in your browser
URLs have rules. They cannot contain spaces, certain special characters are reserved for structural meaning (the question mark separates the path from the query string, the ampersand separates query parameters, the hash sign separates the fragment, etc.), and non-ASCII characters need to be encoded. URL encoding — also called percent-encoding — solves this by replacing problem characters with a percent sign followed by their hex code. This tool encodes and decodes in both directions.
How to use it
Drop your URL, query string, or API parameter value into the editor. Choose Encode (to convert plain text to URL-safe percent-encoded form) or Decode (to convert percent-encoded text back to readable form). Click the button. The result appears instantly. Copy it and use it wherever you need it.
What URL encoding actually does
The URL specification defines a set of "unreserved" characters that can appear literally in a URL: letters (A-Z, a-z), digits (0-9), and a handful of safe punctuation (-, _, ., ~). Anything else has to be encoded. The encoding scheme is simple: take the character's byte value in UTF-8, write it as two hex digits, and prefix with a percent sign. A space (byte value 32, hex 20) becomes %20. An at-sign (byte value 64, hex 40) becomes %40. The accented character "é" (UTF-8 bytes C3 A9) becomes %C3%A9.
Common percent codes
%20— space%21— exclamation mark (!)%23— hash (#)%24— dollar sign ($)%25— percent sign (%)%26— ampersand (&)%27— apostrophe (')%2B— plus (+)%2C— comma (,)%2F— forward slash (/)%3A— colon (:)%3D— equals (=)%3F— question mark (?)%40— at sign (@)
Where URL encoding is required
Search query parameters. If you want to link to a Google search for "best coffee in Tokyo", the URL needs to be https://google.com/search?q=best%20coffee%20in%20Tokyo, not the literal version with spaces (which is invalid).
Form data submitted via GET. Form fields submitted as URL parameters need their values URL-encoded so that special characters do not break the URL structure.
API requests. REST APIs that take parameters in the URL need every parameter value encoded. A parameter like a user's name that contains a space, an ampersand, or any non-ASCII character must be percent-encoded.
Email and SMS links. A mailto: link with a pre-filled subject and body needs both encoded — otherwise spaces, line breaks, and special characters in the subject or body would break the link.
Sharing links with parameters. When you build a "Share on Twitter" or "Share on Facebook" link, the text being shared is passed as a URL parameter and must be encoded.
UTM tracking codes. Marketing campaign URLs with UTM parameters often contain spaces or special characters that must be encoded.
Tracking and analytics URLs. Many tracking systems pass campaign info in the URL, and that info often needs encoding.
Encoding vs. decoding — when you need each
Encode when you have plain text and need to embed it into a URL. Decode when you have a URL (perhaps copied from your browser's address bar, or pulled from a database) and want to see the original readable text. Decoding is often the more useful direction in day-to-day work — many URLs in the wild are heavily encoded and decoding makes them readable.
%20 vs. + — a small but common confusion
Both are sometimes used to represent a space in a URL, but they belong to slightly different specifications. %20 is the canonical URL encoding for a space and works in any part of a URL. The plus sign (+) only represents a space inside application/x-www-form-urlencoded data — which is the format used by HTML form submissions with method="GET". In path segments, a literal plus represents itself. This is why the same URL can sometimes have %20 in some places and + in others — they are technically different contexts. Our tool uses %20 by default, which is safe everywhere.
Privacy
Encoding and decoding happen in your browser using built-in JavaScript functions. Your URLs and text are not uploaded, stored, or logged. Safe for confidential URLs, internal API endpoints, or any other sensitive content.