Encode or decode URL components and query-string values — entirely in your browser. Nothing you enter here is ever sent to Brekzy.
Off (default): encodes/decodes a single value — a query parameter or path segment — escaping every unsafe character, including : / ? & =. On: encodes/decodes a complete URL, leaving those structural characters alone and only touching things like spaces and non-ASCII text.
Copied!
URL encoding is a way of representing text inside a URL using only characters a URL is guaranteed to handle safely. Anything outside that safe set — a space, an ampersand meant as literal text rather than a separator, an accented letter, an emoji — gets rewritten as one or more %XX sequences, where XX is a two-digit hexadecimal byte value. This is also called percent-encoding, after the % character that marks each encoded byte.
A URL can only safely contain a limited set of ASCII characters: letters, digits, and a small handful of punctuation marks that already have defined jobs, like : / ? # & =. Everything else — spaces, quotation marks, non-Latin scripts, emoji, or a reserved character being used as literal data instead of as a separator — has to be represented some other way, or it risks being misread, truncated, or rejected by whatever software receives the URL. Percent-encoding solves this by converting each problem character into its raw byte value, written as % followed by two hex digits, so the URL as a whole stays inside the safe character set no matter what it's carrying.
These two get confused because both turn "unsafe" input into something ASCII-safe, but they solve different problems. URL encoding replaces specific unsafe characters with %XX sequences and is meant specifically for making text safe to place inside a URL — most characters pass through completely unchanged. Base64 goes further: it re-represents arbitrary binary data (not just a handful of special characters) as a fixed alphabet of 64 printable characters, and it isn't specific to URLs at all — it's just as commonly used for embedding images in CSS, encoding email attachments, or storing binary data as text. If you need to encode arbitrary binary data rather than a text value bound for a URL, use the Base64 Encoder & Decoder instead.
These are two unrelated mechanisms that get confused because both encode "unsafe" characters using a marker symbol. URL encoding (percent-encoding) uses %XX sequences and exists to make text safe to place inside a URL - it has nothing to do with HTML markup. HTML entity encoding uses sequences like &, <, and > and exists to safely embed characters inside HTML markup, so a literal < in your text isn't mistaken for the start of a tag. A URL printed inside an HTML attribute, such as an href, can need both at once: percent-encoding for the URL's own special characters, and HTML entity encoding (typically just for a literal &) so the surrounding markup stays valid. Applying one where the other is needed won't produce a working result - this tool performs percent-encoding only, not HTML entity encoding.
A "URL component" is a single piece of a URL's data — for example, the value of one query parameter, or one segment of the path. A full URL, by contrast, is built from several such pieces joined together by structural characters: scheme://host/path?query=string&more=params, where :, /, ?, &, and = all carry structural meaning rather than being part of any one value. That's why component-encoding (the default mode above) is the right default: when you're building a query string or inserting a single value into a URL, you want that value's own special characters escaped without touching the surrounding structure. Full-URL encoding is the special case, reserved for the rarer situation where the input you're handed is already a complete, assembled URL.
Encoding a value before appending it to a query string, so a space or an & inside the value doesn't get mistaken for part of the URL's structure. Preparing a search term, an email address, or free-form text so it can be safely inserted into a link. Decoding a URL you copied from a browser's address bar or an API response that has %20, %26, or similar sequences in it, so you can read it as plain text. Debugging a broken link by checking whether it was encoded correctly in the first place.
URL encoding, also called percent-encoding, is a way of representing characters that aren't safe to use literally inside a URL. Each unsafe character is replaced with a "%" followed by two hexadecimal digits representing that character's byte value, so a URL stays made up of a limited, safe set of ASCII characters no matter what text it needs to carry.
%20 is the percent-encoded form of a space character. Spaces aren't allowed literally in a URL, so encoding replaces each one with %20 (or, in some older query-string conventions, a "+").
Yes. Paste percent-encoded text into the input, choose Decode, and this tool converts it back to its original, readable form.
No. Everything happens in your browser using JavaScript's built-in encoding functions. Nothing you type or paste here is sent to Brekzy or stored anywhere.
URL encoding represents specific unsafe characters as %XX sequences and exists specifically to make text safe inside a URL. Base64 re-represents arbitrary binary data as a fixed alphabet of printable characters and has nothing to do with URLs in particular -- see the comparison section above for more detail.
That happens when a full URL is run through component encoding by mistake. Component encoding escapes every character that isn't safe inside a single URL piece, including the ":", "/", "?", and "=" characters a full URL depends on for its own structure. Check "Treat input as a full URL" before encoding a complete URL so those structural characters are left alone.
Yes. Encoding correctly converts accented letters, symbols, and non-Latin scripts into their percent-encoded UTF-8 byte sequences, and decoding converts them back to the original text.
No. This tool uses JavaScript's standard percent-encoding functions, which treat "+" as a literal character in both directions - encoding it to %2B and never converting a "+" in your input back into a space when decoding. Treating "+" as a space is a separate convention from the older application/x-www-form-urlencoded format used for HTML form submissions, not a rule of percent-encoding itself, and this tool does not apply it.
Explore Brekzy's growing collection of free calculators, converters, AI tools, and practical resources.