Base64 Encode/Decode
Encode text to Base64 or decode Base64 to text instantly. Free online Base64 encoder and decoder tool.
Base64 is a standard encoding scheme that converts binary data into a string of printable ASCII characters. It is named after the 64 characters it uses: the uppercase and lowercase English alphabet, digits 0–9, plus (+), and slash (/). Because it uses only safe characters, Base64-encoded data can be embedded in JSON, XML, HTML, email bodies, URLs, and HTTP headers without corruption.
Common uses of Base64 encoding include embedding images or fonts directly in CSS as data URIs (data:image/png;base64,...), encoding binary attachments in email (MIME), transmitting binary payloads in JSON API requests, and forming the header and payload sections of JSON Web Tokens (JWTs). When working with any of these formats, you will frequently need to encode to or decode from Base64.
It is important to understand that Base64 is encoding, not encryption. The original data can be recovered by anyone who decodes it. If you need to protect data, use encryption (AES, RSA, etc.) — not Base64. Base64 only changes the representation, not the confidentiality of the data.
This tool encodes text to Base64 and decodes Base64 back to text. Switch between Encode and Decode modes, paste your input, and get instant results. All processing happens locally in your browser using JavaScript's built-in btoa() and atob() functions. Your data never leaves your device.
Standard vs URL-safe Base64
RFC 4648 defines two variants. Standard Base64 uses the alphabet A–Z, a–z, 0–9, +, /, with = padding. URL-safe Base64 (Base64url) replaces + with - and / with _, and often omits padding. Base64url is what JWTs use, because URL path components and query strings would otherwise require additional percent-encoding for + and /.
Padding rules
Base64 encodes three bytes into four characters. When the input byte count is not divisible by three, the encoder emits one or two = characters so the output length is always a multiple of four. A string with invalid padding (for example, a single = where two are needed) will fail to decode in a strict parser. If you are building interop between two systems, decide whether the consumer side should accept unpadded input — most modern libraries have a flag for it.
Size overhead
Base64 inflates data by roughly 33%: three bytes of input become four characters of output, and each character is at least one byte on the wire. For small payloads this is negligible; for megabyte-scale blobs embedded in JSON it matters, and you should consider whether a separate binary transport (multipart upload, pre-signed URLs, or a content-addressed store) is a better fit than inlining Base64.
Worked examples
"Hi"(2 bytes) encodes toSGk=— two characters of data plus one=of padding."Hello"(5 bytes) encodes toSGVsbG8=— seven characters plus one padding byte.- Basic HTTP authentication encodes
username:passwordas Base64 and sends it asAuthorization: Basic <blob>. Because this is trivially reversible, Basic auth must always be used over HTTPS.
Related reading
For a deeper look at the common gotchas — line breaks, padding, URL-safe variants, and why Base64 is not encryption — see our article on Base64 in HTTP headers: pitfalls and fixes.