Twenty-five questions on percent-encoding — from what it is and how to do it in JavaScript, Python, Java, Go, and PHP, to %20 vs +, encoding versus HTML and Base64, double-encoding, and the SEO and security angles. Need the tool? Open the URL encoder.
URL encoding — formally percent-encoding, defined in RFC 3986 — converts characters that aren’t safe in a URL into a % followed by their two hexadecimal digits. A space becomes %20, ? becomes %3F, and a non-ASCII character like é becomes its UTF-8 bytes %C3%A9. It lets special characters travel safely inside a URL that only permits a limited ASCII set.
The HTTP request line only allows a limited subset of US-ASCII. If special characters, spaces, or non-English text are placed into a URL raw, intermediate proxies, load balancers, and servers can misread the URL syntax and drop or break the request. Encoding turns those characters into %XX sequences so the URL stays valid end to end.
They solve different problems. URL encoding makes a string safe to travel inside a URL — a space becomes %20. HTML encoding makes a string safe to display inside a web page without being read as markup — < becomes <, which helps prevent cross-site scripting. A value used in both places needs each applied in its own context; they aren’t interchangeable.
There’s no length limit in the HTTP standard itself, but practical limits exist. A conservative ceiling of around 2,000 characters keeps a URL safe across old browsers and picky infrastructure, though modern browsers and servers handle far more. If you’re approaching that, switch from a GET query string to a POST body — see our troubleshooting guide for the specific server limits (Apache, Nginx, CDNs).
URL encoding escapes individual unsafe characters as %XX, keeping text mostly readable — best for query values and paths. Base64 converts arbitrary binary data into a continuous stream of 64 safe characters — best for embedding files or binary payloads. One catch: standard Base64 output contains + and /, which still need URL-encoding unless you use the URL-safe “Base64URL” variant.
No. Encoding is a formatting change, not encryption — anyone can reverse a percent-encoded string instantly, so it gives zero confidentiality. Sensitive values belong in the body of an HTTPS POST request, never in a URL, where they end up in browser history, server logs, and referrer headers. Encode for transport safety, not secrecy.
Use encodeURIComponent(string) for an individual query value, path segment, or fragment — it escapes structural characters like ? & =. Use encodeURI(string) only for a complete URL, where you want to keep structural tokens like :// and / intact. For building query strings, URLSearchParams is usually the cleanest option.
Use the urllib.parse module. urllib.parse.quote(string) percent-encodes a path string; urllib.parse.quote_plus(string) encodes spaces as + for form data; and urllib.parse.urlencode(dict) turns a dictionary of key-value pairs into a full query string in one call.
Use java.net.URLEncoder.encode(text, StandardCharsets.UTF_8). Always specify UTF-8 explicitly — omitting the charset lets the platform fall back to an unpredictable system default and distort multi-byte characters. Note URLEncoder follows form-encoding rules, so it encodes spaces as +.
Use the net/url package. url.QueryEscape(string) encodes a value for a query string, converting spaces to + per form rules; url.PathEscape(string) encodes a path segment, where a space becomes %20. Pick the one that matches where the value goes.
PHP has two functions. rawurlencode($string) follows RFC 3986 and encodes spaces as %20 — use it for path segments. urlencode($string) follows the older form convention and encodes spaces as + — use it for form-style query data. Choosing the wrong one is a common source of +-versus-space bugs.
There’s no single cross-platform SQL function for it. Approaches vary by engine — some teams write a small user-defined function, and PostgreSQL can assemble encoding with string and byte helpers. In practice it’s usually cleaner to encode in your application layer or a tool than inside SQL.
Double-encoding is encoding a string that was already encoded, so %20 becomes %2520 (the % itself becomes %25). Prevent it by encoding raw user input once, at the boundary where you build the request — never re-encode a value that’s already part of a URL. To recover a double-encoded value, decode it recursively.
Two different standards. RFC 3986 encodes a space as %20 everywhere in a URL. The separate application/x-www-form-urlencoded convention — defined in the WHATWG URL Standard and used by HTML forms and URLSearchParams — encodes a space as +. %20 is the safer default; reserve + for form bodies.
Running encodeURIComponent over a full URL encodes its structure along with its data, so https://example.com/ turns into https%3A%2F%2Fexample.com%2F — unroutable. Split the URL into parts, encode only the individual dynamic values, then assemble the final URL around them.
Percent-encoding operates on bytes, so the charset determines the result. The letter é is one byte in ISO-8859-1 (%E9) but two bytes in UTF-8 (%C3%A9). If the encoder’s charset doesn’t match what the receiver expects, the decoded text comes out garbled. UTF-8 is the modern default and the right choice for almost all new work.
RFC 3986’s unreserved set is always safe and never altered by correct encoding: the letters A–Z and a–z, the digits 0–9, and four marks — hyphen -, underscore _, period ., and tilde ~. Everything else is either reserved or must be encoded when it appears as data.
A Web Application Firewall inspects incoming requests for malicious patterns. Attackers sometimes double-encode or use mixed-case hex to disguise a payload from a firewall that only decodes once. The takeaway for developers is defensive: encode consistently, and validate input after fully decoding it, not before. This is background on how encoding is abused, not a technique to use.
Google decodes and crawls percent-encoded URLs without any ranking penalty, so functionally they’re fine. The real cost is human: a URL full of raw hex is harder to read and less likely to be clicked or shared in search results. Prefer readable slugs where you can, and reserve encoding for characters that genuinely need it.
Use clean UTF-8 percent-encoding, which is what Google recommends. A path like /gemüse should encode as /gem%C3%BCse. Google can decode UTF-8 paths and display the native characters in results, keeping international URLs both portable and readable.
Yes. The hex digits are case-insensitive per RFC 3986, but crawlers and analytics often treat the raw strings as distinct keys — so /caf%C3%A9 and /caf%c3%a9 can be indexed as two pages, splitting link equity. Emit one consistent case (uppercase is the RFC recommendation) and normalize at your CDN or proxy. See the troubleshooting guide for the full fix.
The browser treats # as the start of a fragment and never sends it — or anything after it — to the server. An unencoded # inside a campaign value silently drops your tracking parameters before they reach analytics. Encode it as %23 when it’s data, and build query strings with URLSearchParams instead of manual concatenation.
It depends whether the tool runs on a server or locally. urlencodedecode.com encodes entirely in your browser with client-side JavaScript — your input never leaves the tab, and it keeps working offline. That makes it safe for values containing tokens or other sensitive strings. Always confirm a tool is client-side before pasting anything sensitive.
Ordinary strings and even long lists encode instantly. Very large inputs — multi-megabyte files — can slow or freeze a browser tab, since everything runs in memory on your machine. For everyday encoding and batches you won’t hit a limit; for huge files, a command-line tool is the better fit.
For very large files, command-line utilities stream data and aren’t bound by browser memory. A short Python script using urllib.parse, or shell tooling, will encode files that would overwhelm a browser tab. For interactive, one-off encoding, the browser tool is faster and needs no setup.
The answers above rest on the primary web standards that define percent-encoding, plus the official language documentation for the encode functions named:
application/x-www-form-urlencoded serializer — the +-for-space convention used by HTML forms and URLSearchParams. url.spec.whatwg.orgé becomes %C3%A9. rfc-editor.org/rfc/rfc3629urllib.parse, Java java.net.URLEncoder, Go net/url, PHP rawurlencode/urlencode, and JavaScript encodeURIComponent (MDN). Each language’s own docs are the authority on its exact behaviour.Honest scope: the SQL and browser-memory notes describe general engine and environment behaviour, not anything fixed by a standard. The security answers describe how encoding is abused defensively — they aren’t an endorsement of any technique.
Written and maintained by the urlencodedecode.com team. Every technical claim on this page is verified against primary sources — the RFCs (3986, 3629, 4648, 7578), the WHATWG URL Standard, and official vendor or language documentation — rather than second-hand summaries. When a source contradicts a common assumption, we follow the source and note the discrepancy. Corrections: contactus@urlencodedecode.com.