Move data between hex, Base64 and the rest

Text, hexadecimal, binary, Base64, Base64url and URL percent-encoding, converted in your browser. Unicode is handled properly through UTF-8, and malformed input is refused with an explanation rather than silently mangled.

HomeCryptography & Security › Encoding Converter
Encoding is not encryption

Base64 hides nothing. Anyone who sees it can turn it back into the original in one step, with no key and no secret — that is the entire purpose of an encoding. If you need something to be unreadable to whoever holds it, you want text encryption, not this page.

Processed locally in your browserNothing you enter here is uploaded, logged or sent to any server.

How Unicode is handled

Everything goes through UTF-8. Text is turned into bytes with UTF-8 before being encoded, and bytes are turned back into text with UTF-8 after being decoded — so an emoji, an accented letter and a Chinese character all survive a round trip intact.

This is where the browser's own btoa falls down: it throws on any character above U+00FF, which is why so much code contains a workaround involving unescape(encodeURIComponent(...)). Doing the UTF-8 conversion explicitly avoids the problem rather than patching around it.

Decoding is strict in one place on purpose: bytes that are not valid UTF-8 are refused rather than turned into replacement characters. Silently substituting would mean handing back text that looks fine and is not what the bytes said.

Base64 and Base64url are not quite the same

They differ in two characters. Standard Base64 uses + and / for its last two values; Base64url uses - and _ instead, because the other two need escaping in a URL or a filename. Base64url also usually drops the = padding.

JSON Web Tokens, WebAuthn and most modern web APIs use Base64url. A decoder that only accepts the standard alphabet turns a perfectly ordinary JWT into a mystery, so the decoder here accepts either, with or without padding, and tells you which you pasted.

What this tool does not claim

No tool on this site is described as unbreakable, military grade, or completely secure, because none of those phrases means anything a person could check. What is written down instead is which standard is used, which library implements it, and what the tool has been tested against.

Everything here runs in your browser using its built-in Web Crypto implementation. Nothing is uploaded, and there is no server that could receive it. That is a real and checkable property — open your browser's network tab and use the tool.

Which encoding for what

Hex when the value will be compared by eye or quoted in documentation. Two characters per byte, no ambiguity, no case sensitivity to worry about.

Base64 when size matters and the destination is a body or a header — about a third smaller than hex. Base64url when it goes in a URL, a filename, or a JWT.

Percent-encoding for text inside a URL, and nothing else. It is not a general-purpose binary encoding: every non-ASCII byte becomes three characters, so it triples the size of anything that is not English text.

Binary is here for reading, not for transport. Eight characters per byte is useful when you want to see the bits — checking a bitmask, following a hash's avalanche behaviour — and useful for nothing else.

Common confusions

"The Base64 has a = at the end, is it corrupt?" No. Base64 encodes three bytes into four characters, so an input whose length is not a multiple of three is padded with one or two = to fill the last group. It carries no data.

"Why does my Base64 have newlines?" Some tools wrap it at 64 or 76 characters, a convention from email. Whitespace is ignored here.

"It decoded to gibberish." Usually the data was not text — an image, a compressed archive, or a serialised structure. Try hex or byte values and look at the first few bytes; most formats start with a recognisable signature.

Related

The JWT decoder for tokens specifically, the random generator for values to encode, or text encryption when the point is that somebody cannot read it.

Questions people actually ask

Is Base64 a form of encryption?

No, and the distinction matters more than almost anything else on this page. Base64 is a way of writing bytes using 64 printable characters so they survive systems that mishandle binary. Anyone who sees it can reverse it in one step with no key. If the point is that somebody cannot read it, you need encryption.

What is the difference between Base64 and Base64url?

Two characters. Standard Base64 uses + and / for its last two values; Base64url uses - and _ because the other two need escaping in URLs and filenames, and it usually drops the = padding. JWTs and most modern web APIs use Base64url. The decoder here accepts either, padded or not, and tells you which you pasted.

Why does my Base64 end in one or two equals signs?

Base64 turns three bytes into four characters. When the input length is not a multiple of three, the final group is padded with = to fill it out. The padding carries no data, which is why Base64url can drop it.

Does it handle emoji and non-English text?

Yes. Everything goes through UTF-8 in both directions, so an emoji, an accented letter and a Chinese character all round-trip intact. The browser's own btoa cannot do this — it throws on any character above U+00FF — which is why so much code has a workaround involving unescape and encodeURIComponent.

It says the bytes are not valid UTF-8. What does that mean?

That you are trying to display bytes as text when they are not text — an image, a compressed file, or a key. They are still perfectly good bytes; view them as hex or byte values instead. They are refused rather than shown with replacement characters, because handing back text that looks fine and is not what the bytes said is the worse failure.

Is anything I paste sent anywhere?

No. All the conversion happens in your browser. Nothing is uploaded and there is no server involved.