Part of Text tools: See all Text tools.
What is URL Encoder?
Encode special characters in strings to their percent-encoded URL-safe equivalents, or decode percent-encoded URLs back to readable text. Handles spaces, ampersands, Unicode characters, and all reserved URL characters.
How to use URL Encoder
- Paste your string or URL into the input field.
- Select 'Encode' to convert special characters to percent-encoded format, or 'Decode' to reverse the process.
- Click the action button to perform the conversion.
- Copy the result from the output field.
Why use this tool?
Improperly encoded URLs cause broken links, failed API requests, and data corruption in query parameters. This URL encoder/decoder ensures your URLs and query strings are correctly formatted for web browsers, APIs, and HTTP requests.
FAQ
- What characters get encoded?
- All characters outside the unreserved set (A-Z, a-z, 0-9, hyphen, underscore, period, tilde) are converted to their percent-encoded form, such as %20 for spaces.
- Does it encode the entire URL or just the query string?
- You can encode any string. For full URLs, it is best to encode only the parameter values rather than the entire URL to avoid breaking the protocol and path structure.
- Does it handle Unicode characters like emojis or accented letters?
- Yes, Unicode characters are encoded using UTF-8 byte sequences (e.g., %C3%A9 for 'é').
- What is the difference between encodeURI and encodeURIComponent behavior?
- This tool uses full component encoding (equivalent to encodeURIComponent), which encodes all special characters including /, ?, and &.
- Is this tool free?
- Yes, the URL encoder/decoder is free to use with no limits.
URL Encoder — In-Depth Guide
URL encoding converts special characters into percent-encoded sequences safe for use in web addresses. Spaces become %20, ampersands become %26, and other reserved characters are escaped to prevent them from being misinterpreted as URL delimiters. This is essential when constructing query strings with user-provided data.
Web developers encode URL parameters to prevent injection attacks and ensure links work correctly. A search query containing special characters like question marks or hash symbols would break the URL structure without proper encoding. Form data submitted via GET requests must be URL-encoded to reach the server intact.
API developers encode request parameters when constructing URLs programmatically. OAuth signatures, webhook URLs, and callback parameters frequently require double-encoding to survive multiple levels of URL parsing. Understanding URL encoding prevents subtle bugs where parameters are silently truncated or misinterpreted by intermediary servers.
When debugging web applications, decoding URL-encoded strings reveals the original text hidden behind percent sequences. This is useful when examining browser network requests, server logs, and error messages that display encoded URLs. A quick decode confirms whether the correct parameters were sent in API calls and form submissions.
Why URLs cannot just contain any character
A URL is not free-form text; it is a structured address with a strict, limited alphabet. Only a specific set of characters are allowed to appear literally, because several characters carry special structural meaning — the ? that begins a query string, the & that separates parameters, the / that divides path segments, the # that marks a fragment. If your data contains any of these, or a space, or a non-English character, it cannot go into a URL as-is, because the parser would mistake your data for structure. Percent-encoding solves this: each problematic character is replaced by a % followed by its two-digit hexadecimal byte value, so a space becomes %20 and an ampersand inside data becomes %26. Encoding is what lets arbitrary data ride safely inside a rigidly-structured URL.
The bug this prevents
Skipping encoding produces some of the most confusing bugs in web development, because they are intermittent and data-dependent. A search feature works perfectly until someone searches for "rock & roll" — the unencoded ampersand splits the query string, the server sees a truncated search term and a phantom second parameter, and results come back wrong with no error anywhere. A link with a space in it silently breaks in some clients and works in others. An API call fails only for the records whose names contain a slash or a plus sign. Every one of these traces back to data that should have been percent-encoded and was not. Encoding query-string values is not optional polish; it is the difference between a URL that works for all inputs and one that works only until the data gets interesting.
Encoding and decoding are mirror operations
The tool runs both directions, and you will need both. Encoding takes readable text and makes it URL-safe — what you do when you are building a URL or a query parameter from data. Decoding takes a percent-encoded string and restores the readable original — what you do when you are reading a URL someone gave you, debugging why a request failed, or inspecting what a parameter actually contains. Decoding a mysterious-looking URL full of %20 and %3D is often the fastest way to understand what a link or an API call is really doing. The two operations are exact inverses: encode then decode returns your original, which makes the tool safe to experiment with.
The two encodings people confuse
A subtlety that trips up many developers: there is more than one flavour of URL encoding, and the space character is where they diverge. In a path or a percent-encoded component, a space becomes %20. But in the older application/x-www-form-urlencoded format used by HTML form submissions and many query strings, a space becomes a + instead. This means a + in a URL is ambiguous — it might be a literal plus sign or it might be an encoded space, depending on context. When a decoded value comes out with unexpected plus signs or spaces, this mismatch is usually the culprit, and knowing both conventions exist is half the battle in diagnosing it.
Encode the parts, not the whole
A critical rule that beginners get backwards: you encode the components of a URL — the individual parameter values, a single path segment — not the entire finished URL. If you encode a complete URL, you destroy its structure, turning the ?, &, and / that hold it together into %3F, %26, and %2F, producing a string that is no longer a working address. The right mental model is: build your URL's skeleton with its real structural characters intact, then encode only the data you are slotting into each parameter. Encode the value rock & roll to rock%20%26%20roll and place it after the =; leave the surrounding ?q= and &page=2 untouched.
Practical debugging workflow
When a URL-based request misbehaves, decoding is your first diagnostic. Paste the failing URL, decode it, and read what the parameters actually contain — you will often immediately see a value that was double-encoded (an innocent %20 turned into %2520 because something encoded an already-encoded string), or a structural character that leaked into a value. Double-encoding is especially common when a URL passes through several layers that each "helpfully" encode it again; decoding repeatedly until the output stops changing reveals how many layers deep the problem goes. Building URLs by encoding each value once, and debugging them by decoding, will spare you the entire category of mysterious, data-dependent web bugs.
Also try
Related tools that work well with this one: