URL encoder and decoder

This tool accepts one input rather than separate encode and decode fields. Plain text is percent-encoded, converting characters unsafe in a URL, spaces, ampersands, question marks, into percent-encoded bytes. Text already containing a valid percent-encoded sequence, such as %20, is decoded back into readable form instead.

Processing runs client-side, in JavaScript, entirely within your browser. There is no upload and no server round trip, and accordingly no run limit.

A URL permits a limited safe character set unescaped: letters, digits, and a small number of punctuation marks. Any other character, a space, an ampersand, a question mark within a value, a non-ASCII character, must be represented as a percent sign followed by two hexadecimal digits, or it risks being interpreted as structural syntax rather than data.

This is most consequential within a query parameter: a search term containing a space, an email address used as a value, a title containing an ampersand, all require encoding before they can safely traverse a link.

A single field, with direction determined automatically.

Step 1

Paste the text or URL component into the input field.

Step 2

Run the conversion. Already percent-encoded input is decoded; other input is encoded.

Step 3

Read the result.

Letters, digits and a small set of characters designated safe are returned unchanged. Every other character, spaces, ampersands, question marks, colons, slashes, and accented or non-Latin characters, is converted to one or more percent-encoded bytes.

A space becomes %20. An ampersand becomes %26. A character outside the ASCII range is represented across multiple percent-encoded bytes, since it occupies more than one byte in its underlying encoding.

An unencoded ampersand within a query parameter's value is interpreted as the start of the subsequent parameter, silently corrupting the data. A literal space can invalidate a URL outright, since raw spaces are not permitted within one.

Decoding presents a distinct failure mode: a percent sign not followed by two valid hexadecimal digits cannot be safely decoded and produces an explicit error rather than an incorrect guess.

It searches for a percent sign followed by two hexadecimal digits, a pattern exclusive to already-encoded text. When found, the input is decoded; otherwise, it is treated as plain text and encoded.

A coincidental percent-digit sequence within plain text could be misinterpreted as encoded, so an unexpected result warrants checking the input for this case.

A value that mixes encoded and unencoded segments, part of a string already percent-encoded and part still plain, is decoded as one unit rather than segment by segment, since the direction check runs once against the whole input. A coincidental percent-hex pattern inside an otherwise plain string can trigger a decode nobody intended, which is worth checking for if a result looks wrong.

Percent-encoding solves exactly one problem: making a value safe to sit inside a URL. It does nothing for a value destined elsewhere. A string safely percent-encoded for a query parameter is not automatically safe to insert into HTML, where an ampersand or an angle bracket needs its own distinct escaping, or into a SQL query, where an entirely different set of characters carries meaning unrelated to URL structure.

Treating a percent-encoded value as sanitized for any context beyond the URL itself is a common and consequential mistake. Each destination, a URL, an HTML document, a SQL statement, a shell command, has its own syntax and its own escaping rules, and encoding for one does not carry protection into another.

Engineers construct a query string by encoding a search term or redirect URL before embedding it in a link, and decode a URL retrieved from server logs or a browser address bar back into readable form.

Anyone diagnosing a malfunctioning link with unexpected characters uses this to determine precisely what a percent-encoded sequence represents, rather than inferring it from raw bytes.