Base64 represents arbitrary binary data using only 64 printable ASCII characters. You reach for it whenever binary has to travel through a text-only channel: embedding an image directly in HTML, putting credentials in an HTTP header, or nesting a file inside a JSON document.
This tool covers text encoding and decoding, file-to-Base64 with Data URI generation, and URL encoding (encodeURIComponent and encodeURI) in one place. Non-ASCII text — Korean, Japanese, emoji — round-trips correctly through UTF-8, and the URL-safe base64url variant used by JWTs and query parameters is supported.
How to use
- Choose a mode — Switch between Text, File → Base64 and URL encoding. In text mode you can flip between encoding and decoding, and the swap button moves the result back into the input.
- Set the options — URL-safe replaces
+and/with-and_and drops padding — required for JWTs and query parameters. The 76-character wrapping option matches MIME email conventions. - Convert a file — Drag a file in or pick one and you get both the Base64 string and a
data:URI, with a preview for images. The file is read in memory and never uploaded. - Copy or save the result — Copy to the clipboard or download as a text file. Data URIs can get very long, so the preview shows only the beginning.
Frequently asked questions
Is Base64 a form of encryption?
No. Base64 is encoding, and anyone can reverse it.
Storing a password or API key in Base64 is not a security measure; it only makes the value less obvious at a glance. HTTP Basic auth uses Authorization: Basic <base64> not for secrecy but so a colon-containing string can travel safely in a header — which is exactly why Basic auth must only ever run over HTTPS. When you need actual confidentiality, use real encryption such as AES.
Non-ASCII text sometimes comes back garbled.
This tool encodes as UTF-8, so Korean, Japanese and emoji round-trip exactly.
Garbling usually means the other system used a different character encoding. The legacy btoa() handles only Latin-1 and throws on multi-byte input, and PHP or Java code that does not specify a charset may produce bytes in the platform default. Base64 operates on bytes, so both sides must agree on which encoding produced those bytes.
Should I inline images as Data URIs?
For tiny assets, yes. For large ones, no.
Base64 inflates data by roughly 33%. More importantly, an inlined image cannot be cached separately — the browser re-downloads it inside the HTML or CSS file every time that file changes. Inlining icons and logos of a few kilobytes to save a request is reasonable; photographs should stay separate resources with proper cache headers.
Concepts worth knowing
Three bytes become four characters
Base64 groups the input into three bytes (24 bits), splits that into four 6-bit chunks, and maps each chunk to one of 64 characters (A–Z, a–z, 0–9, +, /) — 6 bits express exactly 64 values.
When the input length is not a multiple of three, = padding fills out the final group. The output is always about 4/3 the size of the input, which is where the 33% overhead comes from.
base64url, the URL-safe variant
Standard Base64's + and / mean other things in a URL, and = collides with query-string syntax. RFC 4648 therefore defines base64url: + becomes -, / becomes _, and padding is omitted.
JWT segments, OAuth PKCE challenges and WebAuthn credential IDs all use it. Feeding base64url into a strict Base64 decoder fails, so conversion is required — the decoder here accepts both forms automatically.
URL encoding solves a different problem
Percent-encoding escapes characters that carry special meaning in a URL. It has nothing to do with Base64.
encodeURIComponent escapes /, ?, & and = as well, which is what you want when wrapping a single query parameter value. encodeURI preserves URL structure and leaves those delimiters alone. Using encodeURI on a value is a classic bug: an & inside the value gets read as a parameter separator and your data is silently truncated.