Skip to content
Convertitive

URL Encoder & Decoder

Percent-encoding (RFC 3986) for query strings and URL fragments.

URL encoding (or percent encoding) replaces characters that have a reserved meaning in URLs — spaces, ampersands, equals signs, slashes — with a percent sign followed by the character’s UTF-8 byte values in hex. The tool below handles both directions, supports the full Unicode range, and exposes the same two modes JavaScript uses natively: encodeURIComponent (strict) for query-string values, and encodeURI (relaxed) for whole URLs.

Mode
search%20query%20with%20spaces%20%26%20special%3Dchars%3F

How to use

  1. Pick a direction

    Encode turns plain text into a percent-escaped form; Decode does the inverse.

  2. Choose strict or relaxed (encoding only)

    Strict (encodeURIComponent) escapes every reserved character — use it for query-string values. Relaxed (encodeURI) preserves the structure of a full URL.

  3. Paste your value

    Output updates as you type. The decode side will surface a clear error if the input contains a malformed percent sequence.

When to use which mode

ScenarioUse
A single query-string valueStrict
A whole URL with path + queryRelaxed
A path segment (e.g. file name)Strict
An href being constructed from a constant base + variable suffixStrict (just the suffix)

Frequently asked questions

What characters get percent-encoded?
Strict mode encodes everything except A-Z a-z 0-9 -_.~ (the 'unreserved' set per RFC 3986). Relaxed additionally preserves the reserved set: : / ? # [ ] @ ! $ & ' ( ) * + , ; =
Are spaces encoded as %20 or +?
Inside a URL path, always %20. Inside a query string both are technically accepted (the + comes from the older application/x-www-form-urlencoded standard), but %20 is unambiguous. This tool emits %20 in both modes.
Does the encoder handle Unicode?
Yes. Non-ASCII characters are encoded as their UTF-8 byte sequence, with each byte percent-escaped. The decoder reverses this, returning the original string.
Why am I getting 'incomplete percent sequence'?
The input contains a % that isn't followed by exactly two hex digits — usually because some other tool already decoded the value, or because the value was concatenated without escaping.
Is this the same as HTML entity encoding (&)?
No. HTML entities escape characters for safe inclusion inside HTML markup; URL encoding escapes characters for safe transport inside a URL. The two schemes overlap (& is special in both) but use entirely different syntax.
Does decoding ever return something different from the original?
Only if the original was double-encoded. encode(decode(x)) is always equal to x for any valid encoded string; the inverse holds whenever the original had no ambiguous reserved characters.

About

The RFC 3986 reserved set

RFC 3986 defines two character classes. Reserved (: / ? # [ ] @ ! $ & ' ( ) * + , ; =) have special meaning in URL syntax — they delimit components. Unreserved (A-Z a-z 0-9 -_.~) never need encoding. Everything else (spaces, accented letters, emoji, control characters) must be percent-encoded as its UTF-8 bytes.

Why encoding twice goes wrong

If you encode a value that's already percent-encoded, the % sign itself becomes %25, and the user sees gibberish like %2520. Always pair exactly one encode with exactly one decode along each path. This is one of the most common bugs in URL routing logic.