URL Encoder & Decoder
Percent-encode URLs or decode encoded URL strings — entirely in your browser. Your input never leaves the page.
- Runs in your browser
- No upload, no tracking
- Free forever
How it works
A URL encoder converts characters that are unsafe or reserved in a URL — spaces, &, =, ?, # and non-ASCII text — into percent-encoded sequences like %20, so the value survives transport in a query string or path. A URL decoder reverses that back to readable text. This tool uses the browser's own encodeURIComponent and runs entirely client-side, so nothing is uploaded. It is built by JusDB, a managed database operations team, for the URL and connection-string wrangling that surrounds every app.
- 1
Pick a direction
Use the Switch to Decode / Switch to Encode button to flip between percent-encoding text and decoding an encoded string.
- 2
Paste your input
Type or paste into the left panel. Encoding turns a raw URL or value into a percent-encoded string; decoding does the reverse.
- 3
Read the live output
The right panel updates as you type. Invalid percent-encoding is flagged with an error instead of silently corrupting the result.
- 4
Copy the result
Copy the output to your clipboard in one click, or Clear to start over. Nothing ever leaves your browser.
Frequently asked questions
- What is URL encoding?
- URL encoding (also called percent-encoding) converts characters that are not allowed in URLs into a safe format using a "%" sign followed by two hexadecimal digits. For example, a space becomes %20 and an ampersand becomes %26.
- When do I need to URL encode?
- You need to encode URLs when passing query string parameters that contain special characters like spaces, &, =, +, ?, #, or non-ASCII characters such as accented letters or CJK characters.
- What is the difference between encodeURI and encodeURIComponent?
- encodeURI encodes a full URL and leaves characters like / : ? # & = intact. encodeURIComponent encodes a URL component (like a query value) and also encodes those characters. This tool uses encodeURIComponent, which is what you usually want for parameter values.
- Is my data safe?
- Yes. All encoding and decoding is done using browser-native JavaScript functions. Nothing is sent to JusDB or any server.
- Why does decoding sometimes show an error?
- Decoding fails when the input is not valid percent-encoding — for example a lone "%" or "%2" without two following hex digits. The tool reports the error instead of returning a malformed string so you can fix the input.
- Does it handle non-ASCII and emoji?
- Yes. Because it uses encodeURIComponent and decodeURIComponent, accented letters, CJK characters and emoji are correctly encoded as UTF-8 percent sequences and decoded back to the original text.
Understanding percent-encoding in practice
Every URL has a fixed grammar (RFC 3986), and only a small alphabet is legal in raw form. Percent-encoding is the escape hatch: any byte can be written as a percent sign plus its two-digit hex value, so even bytes that would otherwise break parsing travel safely inside a path or query string.
Reserved vs unreserved characters
RFC 3986 splits characters into two camps. Unreserved characters — A–Z, a–z, 0–9 and the four marks - _ . ~ — never need encoding and should be left as-is. Reserved characters such as / ? # [ ] @ ! $ & ' ( ) * + , ; = carry structural meaning: a ? starts the query, a & separates pairs.
The rule of thumb: encode a reserved character only when it appears as data rather than as a delimiter. A literal ampersand inside a search term must become %26, otherwise the parser reads it as the boundary between two parameters and your value is silently truncated.
encodeURIComponent vs encodeURI
Reach for encodeURIComponent when you are encoding a single piece of data — one query value, one path segment, a fragment. It escapes the reserved delimiters too, which is exactly what you want for a value that must not influence URL structure.
Use encodeURI only when you hold an already-assembled URL and merely want to make it transport-safe; it deliberately leaves / : ? # & = untouched so the address keeps working. Encoding a whole URL with encodeURIComponent is a common mistake — it mangles the >scheme and slashes into https%3A%2F%2F.
Building query strings: + vs %20
Spaces have two valid spellings, and the difference trips people up. Under the application/x-www-form-urlencoded rules used by HTML form submissions, a space is encoded as +. Under generic RFC 3986 percent-encoding, a space is %20.
Decoding with the wrong assumption corrupts data: a literal plus sign in form output means a space, but the same plus in a path segment means a literal plus. When you assemble query strings programmatically, prefer URLSearchParams or encodeURIComponent so each value is escaped consistently rather than concatenating raw strings.
Double-encoding, UTF-8, and broken links
Double-encoding is the classic bug: encode a value once, then pass the result through an encoder again and %20 becomes %2520 because the percent sign itself gets escaped. The fix is to encode exactly once, at the boundary where the value enters the URL. If a link renders a stray %25, suspect a second pass.
Non-ASCII text is first converted to UTF-8 bytes, then each byte is percent-encoded, so an accented letter or emoji becomes a multi-byte sequence like %C3%A9. Correct encoding is also a defense: escaping user input before it reaches a query parameter stops a stray & or # from rewriting the request and keeps injected delimiters from being interpreted as control characters.
Encoding often sits next to other transport concerns. If you are stuffing binary or token data into a URL, see the Base64 encoder & decoder, and when you are inspecting a decoded API payload, the JSON formatter makes the structure readable.