URL Encoder
Encode any text for safe use in URLs using percent-encoding. Converts spaces, symbols, and Unicode to their %XX equivalents instantly.
⏱ 7 min read · Complete guide below
URL Encoder
How URL Encoding Works
- 1Type or paste the text you want to encode — a search query, email address, path, or any string that will appear in a URL.
- 2The encoder replaces every unsafe character with its %XX equivalent — a percent sign followed by the character's two-digit hexadecimal ASCII or UTF-8 code.
- 3Click Copy to copy the encoded result and paste it directly into your URL, API request, or code.
Percent-Encoding Quick Reference
The most commonly encoded characters are: space → %20, & → %26, = → %3D, ? → %3F, / → %2F, : → %3A, @ → %40, # → %23, + → %2B, % → %25. Unicode characters are encoded by first converting to UTF-8 bytes, then percent-encoding each byte. The euro sign (€) for example becomes %E2%82%AC.
Why Text Must Be Encoded Before Going in a URL
A URL can only legally contain a small, safe set of characters, and several of those characters carry structural meaning — a ? begins the query string, an &separates parameters, an = divides a key from its value, and a / separates path segments. If you drop raw text containing any of these into a URL, the browser or server will misread where one part ends and the next begins. Percent-encoding solves this by turning each unsafe character into a harmless %XX code, so a value like name=John & Jane becomes name%3DJohn%20%26%20Jane and is transmitted intact. Encoding user input or dynamic values before building a URL is therefore not optional — it is what keeps the URL valid and prevents both bugs and a class of injection vulnerabilities.
Encoding a Component vs a Whole URL
An important distinction trips up many developers: encoding a value is not the same as encoding a whole URL. When you have a single piece of data destined for one part of a URL — a search term, an email address, a redirect target — you want component encoding, which escapes everything except letters, digits, and a few safe symbols. That is what this tool does, and it is the correct choice for query parameter values. Encoding an entire assembled URL, by contrast, must preserve the structural characters (://, ?, &, =, /) so the URL still functions, and uses a gentler encoding. The rule of thumb: encode each dynamic value on its own with component encoding before you slot it into the URL, rather than encoding the finished URL after the fact.
Encoding Is Not Encryption
It is worth being clear that URL encoding provides no security whatsoever. It is a fully reversible, public transformation — anyone can decode a percent-encoded string instantly — so it hides nothing. Its only job is to make text safe to transport inside a URL. If a value is sensitive, encoding it does not protect it: query parameters routinely end up in server logs, browser history, and referrer headers, so genuinely secret data should not be placed in a URL at all, or should be sent in a request body over HTTPS. Think of percent-encoding as packaging that keeps your data intact in transit, not as a lock that keeps it private.
When You Need to Encode a URL Component
API Query Parameters
When building API requests manually or in scripts, any parameter value containing &, =, spaces, or special characters must be encoded to prevent the URL from being misinterpreted.
Search Queries in URLs
If your application generates search URLs (e.g. /search?q=...), the query text must be encoded so spaces, quotes, and punctuation don't break the URL structure.
Redirect and Callback URLs
OAuth flows and SSO providers require the redirect_uri parameter to be URL-encoded because the redirect URL itself contains characters like :, /, and ?.
Embedding File Paths
File paths containing spaces or special characters (e.g. "My Documents/report 2024.pdf") must be encoded before being embedded in a URL path or download link.
Email Addresses in URLs
Email addresses contain @ and . which are safe, but + signs in email addresses (e.g. user+tag@example.com) must be encoded as %2B to avoid being parsed as a space.
Internationalised Content
Non-ASCII text — accented characters, Arabic, Chinese, Japanese, Cyrillic, and emoji — must all be UTF-8 percent-encoded before appearing in a URL.
Frequently Asked Questions
What characters need to be encoded in a URL?
URLs can only safely contain letters (A–Z, a–z), digits (0–9), and a few special characters: hyphen (-), underscore (_), dot (.), and tilde (~). Everything else — including spaces, ampersands, equals signs, slashes, colons, question marks, and any Unicode characters — must be percent-encoded when used as a value inside a URL component such as a query parameter value or a path segment.
What is the difference between encoding a full URL and encoding a component?
Encoding a full URL (using encodeURI) preserves the structural characters like ://, ?, &, =, and / that give the URL its meaning — only truly unsafe characters are encoded. Encoding a component value (using encodeURIComponent) encodes everything except letters, digits, and -_.~, which is what you want for individual parameter values. This tool encodes component-style by default, which is the correct behaviour for encoding query parameter values.
Why is a space encoded as %20 and not as +?
Both %20 and + can represent a space, but in different contexts. The + notation is part of the older application/x-www-form-urlencoded format used by HTML forms. In modern API query strings and URL path components, %20 is the correct encoding per RFC 3986. This tool outputs %20 for spaces, which is universally correct.
When do I need to encode a URL parameter value?
Any time you build a URL programmatically and a parameter value may contain special characters. Common cases include: search queries with spaces or punctuation, callback/redirect URLs passed as a parameter, email addresses in query strings, file paths embedded in URLs, JSON strings or arrays passed as parameters, and any user-supplied input that becomes part of a URL.
Is URL encoding the same as encryption?
No. URL encoding is a reversible transformation that replaces unsafe characters with their percent-hex equivalents. It does not hide or protect the data — anyone can decode it instantly. If you need to transmit sensitive data in a URL securely, use HTTPS to encrypt the connection, and consider whether a URL is the right transport (query parameters can appear in server logs and browser history).
Is the encoding done on my device or sent to a server?
Entirely on your device. The encoder uses JavaScript's built-in encodeURIComponent() function and runs locally in your browser. Your text is never transmitted to any server.
Should I encode the whole URL or just each value?
Encode each dynamic value on its own before you insert it into the URL. Component encoding — which this tool performs — escapes everything except letters, digits, and a few safe symbols, which is exactly right for a query parameter value or path segment. Encoding an entire assembled URL is a different operation that must preserve structural characters like ://, ?, &, =, and /. The reliable pattern is: encode each value first, then build the URL around the encoded values.
Does URL encoding make my data secure?
No. URL encoding is a completely reversible, public transformation — anyone can decode it instantly — so it provides no security or secrecy at all. Its only purpose is to make text safe to place inside a URL. Because query parameters can appear in server logs, browser history, and referrer headers, sensitive data should not be put in a URL merely encoded. Protect confidential values with HTTPS and, where possible, send them in a request body rather than the URL.
Why must a plus sign in an email address be encoded as %2B?
Because the plus sign has a special meaning in the older form-encoding scheme, where + represents a space. If you place an address like user+tag@example.com directly into a query string, the + may be interpreted as a space, corrupting the value. Encoding it as %2B forces it to be treated as a literal plus sign. This is a common real-world gotcha, and encoding the value with this tool handles it correctly.
How are non-English characters and emoji encoded?
Characters outside basic ASCII — accented letters, Arabic, Chinese, Cyrillic, emoji, and so on — are first converted into their UTF-8 byte sequence, and each byte is then percent-encoded separately. That is why one such character can produce several %XX groups; the euro sign, for instance, becomes %E2%82%AC. This is the standard and correct way to carry international text in a URL, and this encoder produces it automatically so the value round-trips back to the original character when decoded.