URL Encoder
Convert text to URL-safe format by encoding special characters.
Enter text to encode:
How to use URL Encoder / Decoder
- 1
Enter your text or URL
Paste the text you want to encode or the URL-encoded string you want to decode into the input box.
- 2
Choose encode or decode
Select Encode to convert text to URL-safe format, or Decode to turn percent-encoded text back to normal.
- 3
Run the conversion
Process the input to instantly transform it in the chosen direction.
- 4
Copy the result
Copy the encoded or decoded output to use in links, query strings, or API requests.
URL Encoding and Percent-Encoding Explained
What URL encoding is
URL encoding, more precisely called percent-encoding, is the mechanism that lets a URL carry characters it could not otherwise represent. A URL is restricted to a small set of ASCII characters, and several of those characters have special structural meaning. Percent-encoding replaces any problematic character with a percent sign followed by the two hexadecimal digits of its byte value, so a space becomes %20 and a hash becomes %23.
The rules are defined in RFC 3986, the standard that governs URI syntax. The goal is simple: make sure a value placed inside a URL is transmitted and parsed exactly as intended, without a stray character being mistaken for a delimiter or being dropped by software along the way.
Reserved versus unreserved characters
RFC 3986 splits characters into groups. The unreserved set is always safe and is never encoded: the letters A-Z and a-z, the digits 0-9, and the four marks hyphen (-), period (.), underscore (_), and tilde (~). These pass through untouched because they carry no structural meaning and are legal everywhere in a URL.
The reserved set is the punctuation that delimits the parts of a URL: the generic delimiters : / ? # [ ] @ and the sub-delimiters ! $ and & ' ( ) * + , ; =. These characters are legal as separators, but when they appear inside a value rather than as a delimiter they must be percent-encoded so a parser does not misread them. For instance, an ampersand inside a query value has to become %26, otherwise it would be read as the start of a new parameter.
The UTF-8 byte basis
Percent-encoding operates on bytes, not on characters directly, and modern URLs use UTF-8 as the byte source. An ASCII character is a single byte, so an encoded ASCII character is one percent-escape. A character outside ASCII is first expressed as its UTF-8 byte sequence, and then each byte is percent-encoded separately, producing one escape per byte.
The accented letter é is the standard illustration. In UTF-8 it is the two bytes 0xC3 and 0xA9, so it percent-encodes to %C3%A9 — two escapes for one visible character. The euro sign, three bytes in UTF-8, becomes %E2%82%AC. This is why non-Latin text expands so much when encoded: each character may turn into two, three, or four percent-escapes depending on its UTF-8 length.
Worked example: encoding a search value
Suppose you want to put the phrase "Q&A: cats + dogs" into a query string. The letters, digits, and the colon's surrounding text stay as words, but the unsafe and reserved characters get escaped. The space becomes %20, the ampersand becomes %26, the colon becomes %3A, and the plus sign becomes %2B because a literal plus would otherwise be read as a space in form data.
The result is Q%26A%3A%20cats%20%2B%20dogs. Dropped into a link as ?q=Q%26A%3A%20cats%20%2B%20dogs, the server decodes it back to the exact original phrase. Notice that every reserved character that was meant as data, not as a delimiter, had to be encoded to survive the trip.
Spaces: %20 versus the plus sign
Spaces have a famous quirk. In the path and most of a URL, a space is encoded as %20. But in the application/x-www-form-urlencoded format used by HTML form submissions and many query strings, a space is traditionally encoded as a plus sign (+). Both conventions are in active use, which is a frequent source of confusion.
The practical consequence is that a literal plus sign in form-style data must itself be encoded as %2B, so it is not mistaken for a space. When you decode, you have to know which convention produced the string: a plus in a form value means a space, while a plus elsewhere usually means a literal plus. This tool handles the standard percent-encoding so your values round-trip cleanly.
Encoding a whole URL versus a single value
JavaScript exposes two functions that map to two different jobs, and choosing the wrong one is a classic bug. encodeURI is meant for an entire URL: it leaves the structural characters : / ? # & = intact so the URL keeps working, encoding only clearly illegal characters like spaces. encodeURIComponent is meant for a single piece of data, such as one query value or path segment: it escapes the reserved delimiters too, so an embedded slash or ampersand cannot break the surrounding URL.
This tool performs component-style encoding — the encodeURIComponent behavior — which is the safe default for inserting an untrusted value between delimiters you control: it escapes the reserved delimiters too, so an embedded slash or ampersand cannot break the surrounding URL. The trade-off is that you should not paste a complete address here, because it will also escape the structural : / ? # & = characters and mangle the link. To encode a whole URL, encode each individual value or path segment and then assemble the finished address yourself.
The double-encoding mistake
Double-encoding is the most common percent-encoding bug. It happens when already-encoded text is encoded a second time. The trigger is the percent sign itself: a percent is a reserved character, so encoding it turns %20 into %2520, because the leading % becomes %25 and the 20 stays. A value that has been encoded twice will display literal escape sequences like %2520 to the end user instead of the intended space.
Avoid it by encoding exactly once, at the moment you build the URL, and by never running a string that already contains percent-escapes through the encoder again. If you see %25 followed by what looks like another escape, you are almost certainly looking at double-encoded data, and the fix is to decode it one extra time or to remove the redundant encoding step in your code.
Where you will use it
Percent-encoding is everywhere a value travels inside a URL. Building query strings for search and filters, constructing links that contain user-entered text, passing parameters to REST APIs, embedding redirect targets inside a return_url parameter, and signing requests that must match byte-for-byte all depend on correct encoding. Web servers and frameworks decode incoming URLs automatically, so the encoded form is usually something you produce rather than read.
A useful habit is to encode each dynamic piece separately as you assemble a URL, rather than encoding the finished string in one pass. That keeps your delimiters intact while making every value safe, and it sidesteps both the under-encoding that breaks links and the double-encoding that corrupts them.
Frequently asked questions
What does URL encoding actually do?
Can this tool both encode and decode?
Does it handle special characters and other languages?
What is the difference between encoding a full URL and a single value?
Is my data private and is the tool free?
Related tools
Keep going with these handy tools