URL Encoder

About percent-encoding

Percent-encoding (also called URL encoding) replaces characters that aren't safe inside a URL — spaces, &, ?, #, non-ASCII letters, and more — with a % followed by their hex byte value. It's how query strings and path segments carry arbitrary text without breaking the URL's own syntax.

Not every character needs encoding, and the exact set that's left alone depends on context. RFC 3986 marks letters, digits, and - _ . ~ as always safe; everything else in the "reserved" set (like / ? # &) is safe only where it isn't already doing syntactic work. There's also a form-specific quirk: application/x-www-form-urlencoded, the format browsers use for HTML form submissions, encodes a space as + instead of %20 — a convention specific to that one content type, not to URLs in general.

Where you'll run into it

• Query string values containing spaces, symbols, or non-Latin text
• Form submissions sent as application/x-www-form-urlencoded
• Encoding redirect URLs or tokens passed as URL parameters
• Making file paths or search terms safe to put in a link

Frequently asked

Is percent-encoding the same as Base64?
No — they solve different problems. Percent-encoding escapes specific unsafe characters within text that's otherwise left readable; Base64 re-encodes entire binary data into a fixed alphabet.

Why do some characters stay the same?
Letters, digits, and a handful of symbols (- _ . ~) are defined as always safe in a URL, so they're left untouched.

Does this encode a whole URL or just one part?
Just the text you paste as a value. Encoding a full URL would also escape the slashes and colons that need to stay literal, so apply it to individual query values, not the whole address.

Why does a space sometimes become + and sometimes %20?
Both are valid, but in different places. Inside a URL's path or query string, a space is properly encoded as %20. The + shorthand is specific to the application/x-www-form-urlencoded format that HTML forms submit as, where a literal + must itself be encoded to %2B to avoid ambiguity. This tool produces %20, which is always correct; if you're building a form-encoded body by hand, swap encoded spaces for +.