How to URL Encode and Decode Strings Online
To URL-encode a string, paste or type your text into the Input field and click Encode. The tool converts all characters that are not safe in URLs — spaces, special characters, Unicode, reserved characters like &, =, ?, and # — into their percent-encoded equivalents (e.g., a space becomes %20, and & becomes %26). The encoded string appears in the Output field and is safe to use in URL query parameters, path segments, or HTTP headers.
To decode a percent-encoded string back to plain text, paste the encoded URL or URL component into the Input field and click Decode. The tool replaces every %XX sequence with the corresponding character. This is useful when reading logs, debugging API requests, or inspecting redirect URLs that contain encoded parameters. If the input contains invalid percent sequences (e.g., a % not followed by two hex digits), the tool will flag the error.
q=mac & cheese must encode the ampersand and spaces to q=mac%20%26%20cheese so the server parses a single parameter rather than two. Similarly, OAuth 2.0 redirect URIs must be fully percent-encoded to prevent authorization code interception attacks. For encoding data payloads rather than URL components, the Base64 Encoder converts binary data to ASCII-safe strings. If you need to format JSON before embedding it in a query string, use the JSON Formatter to validate and minify it first.Why Use This Free URL Encoder & Decoder?
- Handles full UTF-8 and Unicode encoding — accented characters, CJK, emoji, and non-ASCII are all supported
- Encode and decode in the same tool — switch modes without leaving the page
- 100% browser-based — your URLs and query strings never leave your device
- Instant results — no page reload, no button delay
- Correctly handles edge cases: reserved characters, double-encoding detection, and invalid sequences
- Works with any URL structure — query strings, path segments, or data URIs
- Follows RFC 3986 encoding rules — produces standards-compliant output accepted by all modern browsers and servers
Frequently Asked Questions
What is URL encoding and why is it needed?
URLs can only contain a limited set of characters defined by RFC 3986: letters (A–Z, a–z), digits (0–9), and a small set of special characters (-, _, ., ~). Any other character — spaces, ampersands, equals signs, Unicode characters, slashes in query values — must be percent-encoded before inclusion in a URL. Percent encoding replaces each unsafe byte with a % followed by two uppercase hexadecimal digits representing the byte value. Without encoding, browsers and servers may misinterpret special characters, breaking the URL structure. For encoding data payloads rather than URL components, the <a href="/tools/base64-encoder/">Base64 Encoder</a> converts binary data to ASCII-safe text using a different encoding scheme.
Source: RFC 3986 — Uniform Resource Identifier (URI): Generic Syntax
What is the difference between encodeURI and encodeURIComponent?
JavaScript provides two encoding functions with different scopes. encodeURI() is designed for complete URLs and preserves characters that are valid URL structure characters (/, :, ?, &, =, #, @) — it only encodes characters that are truly unsafe in URLs. encodeURIComponent() is designed for individual URL components (a query parameter value, a path segment) and encodes all characters except letters, digits, and -, _, ., ~ — including /, ?, &, = and other structural characters. Use encodeURIComponent() when encoding values that go inside a query parameter. Use encodeURI() when encoding a full URL that already has its structure set.
Why does a space become %20 in some places and + in others?
Both %20 and + represent a space, but in different contexts. %20 is the standard RFC 3986 percent-encoding of a space and is correct everywhere in URLs. The + convention for spaces comes from HTML form encoding (application/x-www-form-urlencoded), where spaces in form field values are encoded as + for historical reasons. Most modern APIs and servers accept both, but %20 is unambiguous and should be preferred in query strings outside of form submissions to avoid confusion.
Source: WHATWG URL Standard — application/x-www-form-urlencoded
What does double-encoding mean and how do I avoid it?
Double-encoding happens when you encode an already-encoded string, turning % into %25. For example, encoding %20 produces %2520 — which decodes to the literal string '%20' rather than a space. This typically happens when a URL is encoded twice: once by your application and once by a library or framework. To avoid it, only encode user-supplied values before inserting them into a URL, and make sure you are not passing already-encoded strings through an encoder again.
How are non-ASCII characters like emoji or Chinese characters URL-encoded?
Non-ASCII characters are first converted to their UTF-8 byte representation, then each byte is percent-encoded individually. For example, the emoji '😀' (U+1F600) encodes to 4 UTF-8 bytes: F0 9F 98 80, which becomes %F0%9F%98%80 in a URL. A Chinese character like '中' (U+4E2D) encodes to 3 UTF-8 bytes: E4 B8 AD, producing %E4%B8%AD. This is mandated by RFC 3986 and the WHATWG URL Standard, which require that all Internationalized Resource Identifiers (IRIs) be encoded as UTF-8 before percent-encoding. Older encodings like Latin-1 or Shift-JIS should not be used in modern URLs.
Source: RFC 3987 — Internationalized Resource Identifiers (IRIs)
Is URL encoding the same as HTML encoding?
No, they are different encoding schemes for different contexts. URL encoding (percent-encoding) replaces unsafe URL characters with %XX hex sequences and is used inside URLs and query strings. HTML encoding (character entity encoding) replaces characters that have special meaning in HTML — like < becomes <, > becomes >, and & becomes & — and is used inside HTML document content to prevent XSS attacks and rendering issues. Using the wrong encoding in the wrong context is a common source of security vulnerabilities: URL-encoded values placed directly in HTML can enable cross-site scripting, and HTML-encoded values in URLs can break query parameter parsing.
By UtilDaily · Updated \u2014 free, privacy-first browser tools. No sign-up, no data collection.