URL Encoder / Decoder

Q: What's the difference between %20 and + for encoding spaces?

%20 is the standard percent-encoded representation of a space and works correctly anywhere in a URL. A + sign is a older, form-specific convention (from application/x-www-form-urlencoded) that only means "space" inside a query string, and only by that specific convention, not as a general URL encoding rule. This tool always uses %20, the safer, universally correct choice.

Make text safe to use inside a URL, or decode an encoded URL back to readable text.

What is URL Encoding?

URLs can only safely contain a limited set of characters. Anything outside that set, spaces, ampersands, question marks, non-English characters, and more, needs to be converted into a "percent-encoded" format (like %20 for a space) so browsers and servers interpret the URL correctly instead of breaking it into unintended parts. This restriction traces back to the earliest URL specifications, which needed a text format that would transmit reliably across every server, proxy, and piece of network infrastructure on the internet, many of which historically couldn't be trusted to handle spaces or unusual characters correctly inside what's supposed to be a single, unbroken address.

Full URL vs URL Component Encoding

This tool offers two modes. Component encoding (the default) escapes everything that isn't safe inside a single URL parameter, including characters like &, =, and / that would otherwise be misread as part of the URL's structure. Turn the option off for full URL encoding, which leaves structural characters like :, /, ?, and & untouched, since those are meant to keep their meaning in a complete URL, this mode mainly escapes spaces and unsafe characters. Choosing the right mode comes down to a single question: is the text you're encoding meant to be one single value inside a URL, or is it meant to be the URL itself?

Common Uses

Safely passing a search query or user input as part of a URL parameter
Debugging a broken link that contains unexpected characters
Decoding a long, encoded URL to read what it actually contains
Preparing a value to send inside an API request URL
Sharing a link that contains spaces, symbols, or non-English characters without it breaking when pasted
Reading a webhook or callback URL to confirm exactly what data it's carrying before trusting it

A Worked Example

The default text loaded into this tool, https://calc369.com/search?q=hello world & more, demonstrates the difference between the two modes clearly. With Component encoding on (the default), the result is https%3A%2F%2Fcalc369.com%2Fsearch%3Fq%3Dhello%20world%20%26%20more, every special character, including :, /, ?, =, and &, gets escaped, which is correct when this whole string is meant to be used as a single parameter value inside a larger URL, but would break the link entirely if used as the address itself. With Component mode off (full URL encoding), the result is https://calc369.com/search?q=hello%20world%20&%20more, only the space characters get escaped, while :, /, ?, and & stay untouched since they still carry their structural meaning, correctly forming a working, clickable link.

How Percent-Encoding Actually Works

Percent-encoding represents an unsafe character as a percent sign followed by that character's byte value written in two hexadecimal digits, a space (byte value 32 in decimal, 20 in hex) becomes %20, an ampersand (byte value 38, or 26 in hex) becomes %26. For non-ASCII characters, letters with accents, non-Latin scripts, emoji, the character is first converted to its UTF-8 byte sequence, and each individual byte of that sequence gets its own percent-encoded triplet, which is why a single accented letter like "é" expands into two encoded triplets (%C3%A9), and a single emoji can expand into four (%F0%9F%98%80 for 😀). This byte-level, rather than character-level, encoding is what makes percent-encoding able to represent literally any text, in any language, using only the limited set of characters a URL is allowed to contain.

Unreserved vs Reserved Characters

The URL specification (RFC 3986) defines a small set of "unreserved" characters, letters, digits, and the four symbols -, _, ., and ~, that are always safe and never need encoding anywhere in a URL. Every other character falls into either "reserved" (characters like :, /, ?, &, and = that carry structural meaning depending on where they appear) or simply unsafe outside that set entirely (spaces, quotes, angle brackets, and most punctuation). This distinction is exactly why this tool offers two modes: component encoding escapes both the reserved and unsafe characters, since a parameter value should never contain unescaped structural characters, while full URL encoding leaves the reserved characters alone, since a complete URL needs them to keep their structural meaning intact.

Where URL Encoding Fits Into Web Development

Encoding a URL correctly matters most wherever dynamic, user-controlled data ends up inside a link, a search box's contents becoming a query parameter, a filename becoming part of a path, a user's comment being embedded in a shareable link. Most modern frameworks and languages handle this encoding automatically behind the scenes, JavaScript's URLSearchParams, Python's urllib.parse, and similar built-in libraries in virtually every language, but understanding what those libraries are actually doing under the hood is valuable for debugging when something goes wrong, a mysteriously broken link, a parameter that arrives at the server garbled, or a redirect that fails silently. Being able to manually encode or decode a suspicious string, exactly what this tool is for, is often the fastest way to isolate whether an encoding mismatch is the actual root cause of a bug.

Debugging With This Tool

A URL encoder becomes especially useful when working backward from a broken or suspicious link. Pasting a long, cryptic-looking URL full of %XX sequences into decode mode instantly reveals what it actually says, useful for understanding a tracking link, a redirect URL, or a parameter passed from another system before deciding whether to trust or debug it. It's also a fast way to verify your own code's encoding logic, if you're building a URL programmatically and the result looks wrong, encoding the same input here and comparing the two outputs quickly shows whether the bug is in your encoding step or somewhere else in the pipeline.

Common Mistakes When Encoding URLs

Encoding an entire URL in component mode. As the FAQ covers, this escapes the :// and other structural characters, turning a working link into a broken string, switch to full URL mode for a complete link.

Double-encoding a value that's already encoded. Running an already-encoded string through the encoder again escapes the % signs themselves, producing garbled, doubly-escaped text that won't decode back correctly in a single pass.

Manually replacing spaces with + instead of using proper encoding. The + convention only applies within the specific context of form-encoded query strings, using it as a general substitute for a space elsewhere in a URL isn't standard and can be misinterpreted.

Assuming a decode will always succeed. Text that was never validly encoded, or that's been truncated or corrupted, will fail to decode, this tool surfaces that failure clearly rather than silently returning a wrong or partial result, treat a decode error as a signal to check the source of the text rather than something to work around.

Frequently Asked Questions

Why does encoding a full URL sometimes break it?

If you encode an entire URL using component encoding, structural characters like :// and ? get escaped too, which changes what the browser thinks the URL means. Use the "full URL" mode (component toggle off) when encoding a complete link, and component mode only for individual parameter values.

What happens if I decode invalid encoded text?

You'll see a clear error message rather than a broken result, this usually means the text contains a stray "%" that isn't followed by a valid two-digit hex code.

What's the difference between %20 and + for encoding spaces?

%20 is the standard percent-encoded representation of a space and works correctly anywhere in a URL. A + sign is an older, form-specific convention (from application/x-www-form-urlencoded) that only means "space" inside a query string, and only by that specific convention, not as a general URL encoding rule. This tool always uses %20, the safer, universally correct choice.

Are there characters that never need encoding?

Yes, letters (A-Z, a-z), digits (0-9), and the four symbols - _ . ~ are defined as "unreserved" characters in the URL specification and are never encoded, since they're already always safe to use directly in a URL.

Can encoding a URL twice cause problems?

Yes, double-encoding is a common real bug. Encoding "100% off" once produces "100%25%20off", encoding that result again produces "100%2525%2520off", since the % sign from the first pass itself gets encoded. This nested-encoding often causes broken links or garbled parameters when a URL passes through more than one encoding step by mistake.

Does URL encoding work for non-English characters and emoji?

Yes, this tool handles full Unicode text. Non-ASCII characters are first converted to their UTF-8 byte representation, then each byte is percent-encoded, which is why a single accented letter or emoji can expand into several %XX sequences in the encoded output.