Developer Tools2026-03-307 min read|MJMinjae

URL Encoding Guide: How to Encode & Decode URLs Online 2026

Understand URL encoding (percent-encoding), compare encodeURI vs encodeURIComponent, learn URL parsing, and avoid common encoding mistakes.

Browser address bar with URL encoding visualization and network connections

Every time you click a link, submit a form, or call an API, URLs are working behind the scenes. But URLs have strict rules about which characters are allowed. URL encoding (also called percent-encoding) is the mechanism that converts unsafe characters into a format that can be transmitted over the internet. This guide covers everything you need to know about URL encoding in 2026.

What Is URL Encoding?

URL encoding converts characters that aren't allowed in URLs into percent-encoded format: a percent sign (%) followed by two hexadecimal digits representing the character's ASCII/UTF-8 byte value. For example, a space becomes %20, and the Korean character '가' becomes %EA%B0%80 (three UTF-8 bytes).

Space → %20 (or + in form data)
& → %26 (ampersand, used as query separator)
= → %3D (equals sign, used in key=value pairs)
/ → %2F (forward slash, URL path separator)
? → %3F (question mark, query string delimiter)
# → %23 (hash, fragment identifier)
Non-ASCII characters (Korean, Chinese, etc.) → multiple %XX sequences per UTF-8 byte

Try this tool now:

Try Our URL Encoder/Decoder →

Why Is URL Encoding Necessary?

RFC 3986 defines the characters allowed in URIs. Only a limited set of ASCII characters are permitted: letters (A-Z, a-z), digits (0-9), and a few special characters (-, _, ., ~). Everything else — including spaces, non-English characters, and reserved characters used outside their intended purpose — must be percent-encoded.

Browser compatibility: Browsers may handle unencoded characters differently
Server processing: Web servers parse URLs based on reserved characters like ?, &, and =
Data integrity: Without encoding, special characters in query values could break the URL structure
Internationalization: Non-ASCII characters (Korean, Japanese, Arabic, etc.) must be encoded for reliable transmission

encodeURI vs encodeURIComponent

JavaScript provides two built-in functions for URL encoding, and choosing the wrong one is the most common mistake developers make:

// encodeURI — for encoding a COMPLETE URL
// Does NOT encode: A-Z a-z 0-9 ; , / ? : @ & = + $ - _ . ! ~ * ' ( ) #
encodeURI('https://example.com/path?q=hello world&lang=en')
// → 'https://example.com/path?q=hello%20world&lang=en'

// encodeURIComponent — for encoding a QUERY VALUE
// Does NOT encode: A-Z a-z 0-9 - _ . ! ~ * ' ( )
encodeURIComponent('hello world&lang=en')
// → 'hello%20world%26lang%3Den'

Rule of thumb: Use encodeURI() when you have a complete URL and want to fix spaces/non-ASCII characters. Use encodeURIComponent() when you're building a query string and need to encode a parameter value.

URL Parsing: Breaking Down a URL

Understanding URL structure helps you know what to encode and where. A URL consists of several components:

https://example.com:8080/path/to/page?name=John%20Doe&city=Seoul#section1
|____| |_____________||__||____________||_________________________||________|
proto    host         port   pathname          search (query)          hash

Protocol (scheme): http, https, ftp — never needs encoding
Host: domain name or IP — rarely needs encoding (punycode handles international domains)
Port: number — never needs encoding
Pathname: the path segments — encode each segment individually if it contains special characters
Query string: key=value pairs separated by & — always encode both keys and values with encodeURIComponent
Fragment (hash): the part after # — encode if it contains special characters

Common URL Encoding Mistakes

Double encoding: Encoding an already-encoded string (e.g., %20 becomes %2520). Always check if input is already encoded before encoding.
Using encodeURI for query values: This won't encode & and =, breaking your query string structure.
Forgetting to encode: Passing raw user input into URLs without encoding can cause broken links or security issues (XSS, injection).
Encoding the entire URL with encodeURIComponent: This will break the URL by encoding //, /, ?, etc.
Space encoding confusion: Forms use + for spaces (application/x-www-form-urlencoded), while URLs use %20. Know which context you're in.

Try this tool now:

Encode URLs Now →

Frequently Asked Questions

What's the difference between %20 and + for spaces?

In URL paths, spaces must be encoded as %20. In HTML form data (application/x-www-form-urlencoded), spaces are encoded as +. Both represent a space, but they're used in different contexts. When in doubt, use %20 as it works everywhere.

Do I need to encode all characters in a URL?

No. Unreserved characters (A-Z, a-z, 0-9, -, _, ., ~) don't need encoding. Reserved characters (/, ?, #, &, =, etc.) only need encoding when used outside their reserved purpose — for example, a literal & in a query value.

How does URL encoding handle Unicode/non-English characters?

The character is first converted to its UTF-8 byte sequence, then each byte is percent-encoded. For example, the Korean character '한' is 3 bytes in UTF-8 (0xED, 0x95, 0x9C), so it becomes %ED%95%9C.

Is URL encoding the same as HTML encoding?

No. URL encoding uses percent signs (%20, %26). HTML encoding uses ampersand sequences (&, <). They serve different purposes: URL encoding makes characters safe for URLs, HTML encoding makes characters safe for HTML documents.

Can URL encoding cause security issues?

Yes. Failing to properly encode user input in URLs can lead to open redirect vulnerabilities, XSS attacks, or HTTP header injection. Always encode user-supplied data before including it in URLs.