URL Encoder / Decoder

Encode or decode URLs and URL components instantly. Supports both encodeURI (for full URLs) and encodeURIComponent (for query string values).

Mode: encodeURIComponent encodeURI (full URL)

Input Encoded Output

Common URL Encoded Characters

Character	Encoded	Description
	%20	Space
!	%21	Exclamation mark
"	%22	Double quote
#	%23	Hash / fragment
$	%24	Dollar sign
%	%25	Percent sign
&	%26	Ampersand (query separator)
'	%27	Single quote
(	%28	Open parenthesis
)	%29	Close parenthesis
+	%2B	Plus sign
,	%2C	Comma
/	%2F	Forward slash
:	%3A	Colon
;	%3B	Semicolon
=	%3D	Equals (key=value separator)
?	%3F	Question mark (query start)
@	%40	At sign
[	%5B	Open bracket
]	%5D	Close bracket

What is a URL Encoder/Decoder?

A URL encoder/decoder converts text between its human-readable form and percent-encoded (URL-safe) form — transforming characters that have special meaning in URL syntax into escaped representations that can be safely transmitted as part of a web address. URL encoding (officially called percent-encoding, defined in RFC 3986) replaces each unsafe character with a percent sign followed by its two-digit hexadecimal ASCII code: a space becomes %20, an ampersand becomes %26, a hash becomes %23, and a forward slash becomes %2F. The decoder performs the reverse operation — converting %XX sequences back to their original characters — making percent-encoded URLs human-readable again.

The RFC 3986 URI specification divides characters into two classes: unreserved characters (A–Z, a–z, 0–9, hyphen, period, underscore, tilde) that may appear unencoded anywhere in a URL, and reserved characters (: / ? # [ ] @ ! $ & ' ( ) * + , ; =) that serve as URL syntax delimiters and must be percent-encoded when used as literal data values. A URL query parameter containing a user's search string, for example, must be encoded to prevent the search text from being interpreted as URL structure — a search for "bread & butter" must be encoded as "bread+%26+butter" or "bread%20%26%20butter" to prevent the ampersand from being parsed as a query parameter separator.

Frontend developers use URL encoders when constructing API request URLs with dynamic query parameters, ensuring that user-provided input containing special characters does not break URL parsing. Backend developers use URL decoders to interpret incoming request parameters that browsers automatically encode before submission. JavaScript provides two pairs of encoding functions with different scopes: encodeURIComponent / decodeURIComponent (encodes all characters except unreserved characters — use for query parameter values and path segments) and encodeURI / decodeURI (preserves URL-structural reserved characters — use for complete URL strings). Understanding the distinction prevents double-encoding bugs and broken URL construction in web applications.

How the URL Encoder/Decoder Works

Formula, assumptions, and calculation steps for this dev tools tool.

Formula Used

Replaces reserved or unsafe characters with percent-encoded hex escape sequences per RFC 3986

Methodology

Converts characters unsafe for URLs into percent-encoded hex sequences per RFC 3986, or decodes them back to plain text.

Calculation Steps

Provide the input text or select generation options.
Apply the selected encoding, parsing, hashing, or formatting rule.
Validate the output where possible.
Return copy-ready developer output.

Assumptions and Limits

Generated or transformed output depends exactly on the supplied input.
Security-sensitive values should be handled carefully.
Browser tools do not replace production validation.

Frequently Asked Questions

What is URL encoding?

URL encoding (also called percent-encoding) converts characters that are not allowed in URLs into a percent sign followed by two hex digits. For example, a space becomes %20. This ensures URLs are valid and can be safely transmitted over the internet.

When should I use encodeURIComponent vs encodeURI?

Use encodeURIComponent when encoding individual query string parameters or URL fragments — it encodes all special characters including & = ? / : etc. Use encodeURI for a full URL — it preserves characters like / : ? & = # that have structural meaning in a URL.

Why does space encode to %20 sometimes and + other times?

In standard URL percent-encoding (RFC 3986), space encodes to %20. However, HTML form data uses application/x-www-form-urlencoded format where space encodes to +. If you're building query strings from form data, + may appear; in all other cases expect %20.

Is this encoding the same as Base64?

No. URL encoding (percent-encoding) converts specific characters to %XX hex sequences and is designed for use within URLs. Base64 converts binary data to a text string using 64 ASCII characters and is used for encoding binary data in text contexts like email attachments or data URIs.

Real-World Applications

🔗

API Query Parameter Construction

Backend and frontend developers use URL encoding when dynamically constructing API request URLs with user-supplied query parameters. A search API called with a user query of "coffee & cake near me?" must encode the ampersand and question mark before appending to the URL: ?q=coffee+%26+cake+near+me%3F. Failure to encode produces a malformed URL where the ampersand is interpreted as a parameter separator, splitting the query into invalid fragments and returning incorrect results.

📬

Email Marketing Link Tracking

Email marketers embed UTM tracking parameters in links — URLs like campaign=spring_sale&source=email&medium=newsletter must be encoded when nested inside another URL's query parameter (e.g., as a redirect target). Without proper URL encoding of the inner URL, the outer URL's parameter parsing breaks at the first unencoded & in the inner URL. URL encoder tools help marketers generate correctly encoded tracking links that survive email client URL parsing.

🔐

OAuth & Authentication Token Handling

OAuth 2.0 and OpenID Connect flows pass redirect URIs, state parameters, and code verifiers as URL query parameters — and these values frequently contain special characters that require percent-encoding. The redirect_uri parameter in particular must be precisely URL-encoded in OAuth requests; a mismatch between the registered and submitted redirect URI (caused by encoding inconsistency) is a common source of OAuth authentication failure in development.

🌐

Internationalised URL Handling (IDN)

URLs containing non-ASCII characters — accented letters (é, ü, ñ), Chinese/Japanese/Korean characters, Arabic, and emoji — must be percent-encoded for transmission over the internet. A URL containing "café" in the path must encode the é as %C3%A9 (its UTF-8 byte sequence). Browsers display internationalised URLs in their decoded human-readable form, but actually transmit the percent-encoded version — the URL encoder bridges the gap between what users see and what the protocol requires.

🧪

API Testing & Debugging

Developers testing REST APIs with tools like Postman, Insomnia, or curl use URL encoders to verify that endpoint URLs and query parameters are correctly encoded before making test requests. When an API call returns unexpected errors, decoding the URL (or request log) with a URL decoder reveals whether the endpoint URL or parameter values contain characters that weren't properly encoded — a common debugging step for 400 Bad Request errors caused by malformed URLs.

📄

Web Scraping & Data Extraction

Web scrapers and data extraction scripts encounter percent-encoded URLs in HTML source, HTTP response headers, and sitemap XML files that must be decoded before processing or following as links. URL decoders convert %20 back to spaces, %2F back to slashes, and %E4%B8%AD%E6%96%87 back to Chinese characters, enabling the extracted URLs to be displayed, stored, or compared in human-readable form. Both encoding (for request construction) and decoding (for response parsing) are routine operations in web scraping workflows.

Common Mistakes

Double-encoding URLs by encoding an already-encoded string

Applying URL encoding twice converts % signs (from the first encoding) into %25 — so %20 becomes %2520. A URL containing %2520 will be decoded by the server as the literal string "%20" (with the percent sign), not as a space character. Double-encoding occurs when a URL is encoded at multiple points in a pipeline — when building the URL, then encoding it again before storing, then encoding once more when appending it as a parameter. Always encode only once, at the final point before the URL is transmitted.

Using encodeURI when encodeURIComponent is needed for query parameter values

JavaScript's encodeURI preserves URL-structural characters (: / ? # & = +) unencoded because it is designed for encoding complete URLs. Using encodeURI on a query parameter value that contains & or = leaves those characters unencoded, causing incorrect URL parsing. encodeURIComponent encodes everything except unreserved characters and is the correct choice for encoding individual query parameter names and values. This is the most common JavaScript URL encoding error in frontend code.

Not encoding the space character consistently (+ vs. %20)

In URL query strings, spaces can be encoded as either + (the HTML form encoding convention, used by application/x-www-form-urlencoded) or %20 (strict percent-encoding per RFC 3986). These are equivalent in most web server configurations — but not universally. Some APIs accept only %20 for space; some legacy systems require + in form-submitted query strings. When submitting data through HTML forms, + is correct; when constructing URLs in code, %20 is safer and more portable.

Assuming all URLs in a page's HTML source are ready to use without decoding

HTML attributes (href, src, action) may contain HTML-entity-encoded characters (& encoded as & in HTML source) rather than percent-encoded characters. A URL of /search?a=1&b=2 appears as /search?a=1&b=2 in valid HTML source. Extracting this URL and using it directly without converting & back to & produces a broken URL. Web scrapers must apply HTML entity decoding before URL decoding — the two encoding layers are applied (and must be removed) in the correct order.

Not understanding that percent-encoding is case-insensitive but case is conventionally uppercase

RFC 3986 specifies that percent-encoded sequences are case-insensitive: %20, %2F, and %2f are all valid and equivalent. However, the specification recommends using uppercase hex digits (%20, %2F) for consistency and interoperability. Some systems (particularly older ones) incorrectly treat %2f and %2F as different, or compare encoded URLs without normalising case. When comparing URLs or storing them as database keys, normalise percent-encoding to uppercase before comparison to avoid false "not equal" results.

Common Percent-Encoded Characters Quick Reference

Character	Encoded	URL Role
Space	%20 (or +)	Not a URL character
&	%26	Query parameter separator
=	%3D	Key-value separator
#	%23	Fragment identifier
/	%2F	Path segment separator

References

Berners-Lee, T. et al. RFC 3986: Uniform Resource Identifier (URI): Generic Syntax. IETF, 2005.
WHATWG. URL Standard. url.spec.whatwg.org, 2024.
MDN. encodeURIComponent() — JavaScript Reference. developer.mozilla.org, 2024.
W3C. HTML5 — URL Percent-Encoding. w3.org, 2024.
IETF. RFC 1866: Hypertext Markup Language — 2.0 (Form Encoding). ietf.org, 1995.