URL Encoder / Decoder

URL encoding: keeping special characters from breaking your links

URLs may only contain a limited set of characters. Anything else — spaces, accents, slashes inside a query value, ampersands inside a search term — must be percent-encoded before the URL is sent. Skip the step and the request will either be rejected or, worse, silently parsed wrong: an unescaped &in a search term splits your query into two parameters and nobody gets an error message. The escaping below is done by the browser's own encoder, so the link you are fixing never travels anywhere to get fixed.

How percent-encoding actually works

Encoding replaces each unsafe character with % followed by the hexadecimal value of its bytes. A space is byte 0x20, so it becomes %20; an ampersand is 0x26, so it becomes %26. Characters outside ASCII are first converted to UTF-8 and each byte is escaped separately: é is the two-byte sequence 0xC3 0xA9, which encodes as %C3%A9. Put together, a real search URL transforms like this:

Before: https://example.com/search?q=café & crème
After: https://example.com/search?q=caf%C3%A9%20%26%20cr%C3%A8me

Notice that the structural characters — ://, ?, = — stay untouched, while everything inside the query value is escaped. Decoding reverses the process byte for byte, which is why a correct encode/decode round-trip never loses data.

Component vs. full URL

Use Component when encoding a single piece of a URL — a search term, a path segment, a query value. It escapes everything that could break URL structure, including / and &. Use Full URLwhen encoding a complete URL that you don't want to break — it preserves :/?#&=+ so the URL stays functional. Picking the wrong mode is the most common encoding bug: component-encoding a whole URL turns it into one giant unusable string, while full-URL-encoding a query value leaves dangerous characters unescaped.

Where you'll need this

• Building query strings from user input — search terms, filters, form values
• Passing a redirect or callback URL as a parameter inside another URL (OAuth, login flows)
• Debugging webhooks and API calls by decoding what was actually sent
• Creating mailto: or share links with prefilled subjects and bodies
• Encoding file names with spaces or unicode for download links

Common mistakes

Double-encoding tops the list: encode a value twice and %20 becomes %2520, which decodes back to the literal text %20 instead of a space. Encode exactly once, at the moment the value is inserted into the URL. The plus sign is the other classic trap — HTML forms encode spaces as +, but strict percent-encoding does not, so a + in a query string may mean a space or a real plus depending on who produced it. When in doubt, send %20 for spaces and %2B for a literal plus.

When URL encoding is the wrong tool

Percent-encoding makes text safe for URLs — nothing else. It is not protection against XSS when inserting text into HTML (use HTML entity escaping), it does not hide or secure data (the encoding is trivially reversible), and it is not how you embed binary data in a URL (Base64-URL is far more compact). Reach for the encoder that matches the context the text is going into.

Related tools

• HTML Encoder — escape <, > and & for safe insertion into HTML, the counterpart to URL escaping.
• Base64 Encode / Decode — pack binary or structured data into a compact text form, including the URL-safe variant.
• JWT Decoder— decode the URL-safe tokens you'll often find in query strings and auth headers.
• Regex Tester — build and test the patterns you use to pick apart query strings.