---
title: "URL Encoder / Decoder"
description: "Percent-encode or decode URL components with Unicode support. Instant, offline, nothing leaves your browser."
url: "https://freshjuice.dev/tools/url-encoder/"
---
## About this tool

Type any text and see both the percent-encoded form (safe for query strings and path segments) and the decoded form at once. Encoding uses`encodeURIComponent`, so reserved characters (`&`, `=`, `?`, `#`, spaces) are all escaped — exactly what you want when building query parameters by hand.

## encodeURIComponent vs encodeURI

-   **encodeURIComponent** (this tool) escapes everything reserved — use it for a single query value or path segment.
-   **encodeURI** leaves `:/?#&=` intact — use it for a complete URL you don't want to break.

Unicode is fully supported: emoji and non-Latin scripts encode to their UTF-8 percent sequences.

## Frequently Asked Questions

### When do I need URL encoding?

Whenever a value you're putting into a URL contains characters that aren't URL-safe: spaces, non-Latin scripts, emoji, ampersands, equals signs, anything outside the unreserved set (`A-Z a-z 0-9 - _ . ~`). Query parameters, path segments, and fragments all have reserved characters. Encoding ensures `next=/a?b=c` arrives as data, not as structure the server parses.

### What's the difference between encodeURIComponent and encodeURI?

**encodeURIComponent** (what this tool uses) escapes everything reserved: `&`, `=`, `?`, `#`, spaces. Use it for a single query value or path segment. **encodeURI** leaves `:/?#&=` intact, so you can encode a complete URL without breaking its structure. Rule of thumb: encoding a piece, use `encodeURIComponent`; encoding a whole URL, use `encodeURI`, and even then only if the pieces inside were already encoded.

### Why does a space become %20 or +, and which is right?

Both are legitimate in a query string. `%20` is the percent-encoding of space per RFC 3986; `+` is a legacy HTML form convention (application/x-www-form-urlencoded). Servers decoding query strings accept both. In a path segment, only `%20` is valid: a literal `+` in a path stays a plus sign. This tool outputs `%20` (via `encodeURIComponent`), which is correct everywhere.

### My encoded string looks different from another tool's output. Why?

Usually one of two things. Either the other tool used `encodeURI` and left reserved characters unescaped (see above), or it encoded differently for form contexts (`+` vs `%20`). Also, unreserved characters like `~` and `.` may appear raw or encoded (`%7E`): both decode to the same value, and RFC 3986 says encoders should leave them raw.

### Does it handle Unicode, emoji, and non-Latin scripts?

Yes. Input is first converted to UTF-8, then each byte is percent-encoded, which is exactly how browsers and servers handle URLs. `café` becomes `caf%C3%A9`; an emoji becomes its four-byte UTF-8 sequence. Decode reverses it: percent sequences back through UTF-8 to the original characters.

### What happens if I double-encode?

The encoded string gets encoded again: `a%20b` becomes `a%2520b`, because the `%` itself is escaped to `%25`. Servers then see a literal "%20" instead of a space. It's the most common cause of "my redirect URL got mangled" bugs, usually from encoding a value a framework was already going to encode. The decoded output here shows both forms side by side, so you can spot when an input has been encoded twice.