Useful Utilities

URL Encoder and Decoder

Percent-encode text for a URL component or a whole link (structure kept), or decode escapes back, with the table of every changed character and its code point.

Fill in the values and calculate

Text, path or URL*
DirectionDefault Encode: escape everything, even & ? / #

The form sends itself back to this page — results print below, computed on the server.

No results yet: fill the form above and press Calculate.

About URL Encoder and Decoder

Percent-encoding replaces every character a URL cannot carry with the % escapes of its UTF-8 bytes, so spaces become %20 and accented letters become sequences like %C3%A9. The safe-character set implemented here is the one RFC 3986, the generic URI syntax standard, spells out: in its informative grammar every visible ASCII character may appear literally except % ( ) + , : ; < = > @ [ \ ] ^ { | } and DEL.

Whole-URL mode follows that set and keeps URL structure (slashes, question marks, ampersands) readable, escaping only what no link can carry, control characters included. Component mode adds the structural punctuation and quotes to the escaped set, which is what a single query parameter, path segment or filename needs. Decoding undoes the escapes; a lone % must be written %25, and this page reports where a broken escape sits instead of crashing.

The table lists every changed character in order of appearance: the character itself, its Unicode code point, and what the encoder turned it into (or, when decoding, the escape and the character it restores). Repeated characters are listed once with their count, so the table explains the transformation instead of just printing the result.

Questions about URL Encoder and Decoder

Which mode should I pick?

A value going inside a link - a query parameter, a path segment - needs component mode, because it also escapes & ? / #. A whole link you are pasting into another link needs URL mode, which keeps its structure.

What about spaces?

Both encoder modes write a space as %20. Older form encoders used + instead; decoding will not undo that, so swap + for a space first when the text came from a submitted form.

Why does my decode throw?

A % not followed by two hexadecimal digits makes the text malformed; the browser throws for exactly that reason, and this page reports the position of the first broken escape instead.

Are control characters escaped?

Yes. Characters below the visible-ASCII range RFC 3986 permits literally - tabs, newlines, the C0 and C1 controls - all become the % escapes of their UTF-8 bytes, so nothing invisible survives into a link.

Does decoding give my exact original back?

For encoder-mode outputs, yes: encoding always round-trips through the decoder, and the page says so when it verifies it.

Bookmark and homescreen