How to URL Encode Text: Percent-Encoding Explained
Spaces, ampersands, and accented letters break URLs unless they are percent-encoded first. This guide covers how URL encoding works, when to use it, and how to avoid the mistakes that cause broken links.
URLs can only safely contain a small set of characters. The moment a value has a space, an ampersand, a question mark, or a letter outside plain ASCII, it risks getting cut off, misread, or silently corrupted by whatever parses the link next. URL encoding - also called percent-encoding - is the fix: it rewrites unsafe bytes as %XX sequences that every browser, server, and library understands the same way.
This guide walks through how percent-encoding actually works, when to encode a single value versus a whole URL, and the mistakes that cause broken redirects and mangled query strings. You can follow along with the URL Encoder, which percent-encodes text entirely in your browser as you type.
What is URL encoding?
URL encoding replaces any character that is not allowed - or not safe - in a URL with a % followed by its two-digit hexadecimal byte value. A space becomes %20, an ampersand becomes %26, and so on. The rest of the string, made up of letters, digits, and a handful of punctuation marks, passes through unchanged.
The character set that never needs escaping is called the unreserved set: uppercase and lowercase letters, digits 0-9, and the four symbols - _ . ~. Everything else is either reserved (has special meaning in a URL, like /, ?, &, =, #) or simply outside the ASCII range the URL spec allows.
Encoding a value with accents and reserved characters
Component encoding turns spaces, an ampersand, and UTF-8 letters into %XX escapes.
Input
café & crèmeOutput
caf%C3%A9%20%26%20cr%C3%A8meWhy URL encoding matters
A URL is really a delimited string: / separates path segments, ? starts the query string, & separates parameters, and = joins each key to its value. If a value you insert happens to contain one of those characters unescaped, the parser reading the URL will misinterpret it - splitting a parameter in the wrong place or truncating a path.
- Correctness - a redirect URL, search term, or callback address arrives intact instead of being cut off at the first
&or?. - Fewer support tickets - links shared in emails or chat apps do not break when they contain spaces or punctuation.
- Interoperability - every server, proxy, and browser agrees on what
%20and%26mean, unlike raw spaces or literal symbols. - International support - non-ASCII text (accents, CJK characters, emoji) can travel through a URL only once it has been percent-encoded.
How percent-encoding works
The process has two steps. First, any character outside the unreserved set is converted to its UTF-8 byte representation - a plain ASCII character is one byte, while an accented letter or emoji may be two, three, or four bytes. Second, each of those bytes is written out as % followed by its two-digit hexadecimal value, uppercase by convention.
That is why a single accented letter like é expands to two escapes, %C3%A9, rather than one: it is two UTF-8 bytes, and each byte gets its own %XX. In JavaScript this is what encodeURIComponent() and encodeURI() do under the hood - the URL Encoder exposes both so you can pick the right scope for what you are encoding.
Component mode vs. full-URI mode
Component encoding (encodeURIComponent) escapes almost every character that is not a letter, digit, or - _ . ~, including / ? & = #. Use it whenever you are encoding one query parameter, form field, or path segment on its own - it guarantees the value cannot accidentally break the surrounding URL structure.
Full-URI encoding (encodeURI) is gentler: it leaves the structural characters : / ? # [ ] @ alone because it assumes you are encoding an entire, already-structured URL rather than a bare value. Use it when you need to make a complete URL safe to embed somewhere without destroying its scheme, host, and path separators.
Where does your text go?
Percent-encoding is pure text transformation, so it can run entirely on-device. The URL Encoder never uploads, logs, or stores what you type - which matters when the value is an API key, a session token, or a customer's personal data embedded in a redirect URL.
Step-by-step: encode a value for a URL
- Open the URL Encoder and paste the text or URL you need to make safe - a search term, a redirect target, or a full query parameter.
- Pick the encoding scope: component mode for a single value, or full-URI mode if you are encoding a complete URL and want to keep its structure readable.
- Check the live output as you type - reserved characters, spaces, and non-ASCII letters turn into
%XXescapes instantly. - Copy the encoded string and drop it into your query string,
href, or API request.
There is nothing to install and no account required, and the character and byte counts shown alongside the output make it easy to confirm nothing was truncated.
Common use cases
- Building query strings where a value contains spaces, symbols, or punctuation.
- Encoding a
redirect_urior callback URL for an OAuth or SSO flow. - Embedding a full URL as the value of another URL's query parameter, such as a share link or tracking redirect.
- Preparing a search term before appending it to a GET request.
- Escaping user-supplied text before it is inserted into a generated link, so stray
&or#characters cannot hijack the URL.
Common mistakes and how to avoid them
Encoding a whole URL with component mode
Running an entire URL through encodeURIComponent escapes its own : / and ?, turning https://example.com/a?b=c into an unreadable, unusable string. Component mode is for a single value that will be placed inside a URL, not for the URL itself - use full-URI mode, or encode only the parts that need it.
Assuming + and %20 are interchangeable
A literal + in a query string can mean a space, but only inside application/x-www-form-urlencoded bodies and query strings - not in a URL path. %20 is unambiguous everywhere, which is why standard percent-encoding always produces %20 for a space rather than +.
Forgetting that non-ASCII text needs multiple escapes
Copying an accented name or a string with emoji directly into a URL will fail in some clients. Each non-ASCII character must first become UTF-8 bytes, then each byte becomes its own %XX escape - so one visible character can turn into two, three, or four escapes, as with café becoming caf%C3%A9.
Double-encoding an already-encoded value
Running an already-encoded string through the encoder again turns every % into %25, producing something like %2520 instead of %20. If a value looks like it already contains %XX escapes, decode it first to confirm, then encode only once before reusing it.
Best practices
- Default to component encoding for individual values; reach for full-URI encoding only when the input is a complete URL.
- Encode each parameter value on its own, then assemble the query string - do not encode the whole
key=value&key2=value2string at once. - Keep a matching URL Decoder step in mind whenever you log or display an encoded value, so you can verify what it actually contains.
- When a URL parameter itself carries binary-ish data such as an ID or token, consider Base64 encoding it first and then percent-encoding the result, since Base64 output is shorter than encoding raw text byte-by-byte.
- For sensitive values - tokens, session identifiers, personal data - use a tool that encodes locally rather than one that sends your text to a server.
Related tools
Related guides
A log line full of %3D and %20 is hard to read at a glance. This guide explains how percent-decoding works, the + versus space gotcha, and how to recover the original text instantly and privately.
Base64 encoding turns arbitrary bytes into safe, portable text. This guide covers how encoding works, UTF-8 pitfalls, URL-safe output, and how to encode text or files without uploading anything.
Minified JSON is unreadable and hard to debug. This guide covers how JSON formatting works, when to use it, common mistakes, and how to pretty-print JSON without uploading it anywhere.