link URL Encode / Decode star

How It Works

A URL can only safely carry a small alphabet: letters, digits, and the four unreserved symbols - _ . ~. Everything else gets rewritten as a %XX triplet, where XX is the hexadecimal value of the character's byte — this is RFC 3986 percent-encoding. Characters that structure a URL (? # / : @ & =, the "reserved" set) get encoded too whenever they appear inside a value rather than as delimiters, since a literal & inside a query value would otherwise be read as the start of the next parameter.

Non-ASCII text is encoded byte by byte, not character by character: the tool converts your string to UTF-8 first, then hex-encodes each resulting byte. The Turkish letter "ç" is two UTF-8 bytes (0xC3 0xA7), so it becomes two percent blocks, %C3%A7 — not a single code. A concrete example: encoding İstanbul çayı & simit produces %C4%B0stanbul%20%C3%A7ay%C4%B1%20%26%20simit. Notice the space becomes %20, the reserved & becomes %26, and each accented letter expands into its own multi-byte sequence.

In practice this distinction matters most when hand-assembling requests: pasting a webhook URL with a query value someone sent you, decoding a tracking parameter from a marketing email, or figuring out why an API call fails because a raw & or # slipped unencoded into a value and got read as a delimiter instead of data. Encoding the value first, then substituting the result into the URL template, avoids exactly that class of bug.

What to Know

• %20 vs +: RFC 3986 percent-encoding always uses %20 for a space. The + convention belongs to a different, older standard — application/x-www-form-urlencoded, used when an HTML form submits data — and only applies inside that specific body format, never inside a path or a properly percent-encoded query value. Swapping the two is a classic source of bugs: a server expecting form encoding reads a stray + in a percent-encoded string as a literal plus sign, not a space.
• Encode one component, not the whole URL: this tool is built for a single query value or path segment. Running the entire address (including https://) through the encoder would also escape the slashes and colons that make it a valid URL, breaking it entirely.
• Same engine as your browser: it calls the browser's native encodeURIComponent/decodeURIComponent, so results match exactly what a real browser or JavaScript fetch call would produce — not an approximation.
• Round-tripping is lossless: encoding a string and then decoding the result always returns exactly the original bytes, which makes it easy to sanity-check a manual encoding job by decoding it back and comparing against the source text.
• Nothing leaves your browser: encoding and decoding run entirely client-side, instantly, with no upload.