Base64 encode Decode Calculator
Free Base64encode decode Calculator for encoding & hash. Enter parameters to get optimized results with detailed breakdowns.
Reviewed for accuracy by Daniel Agrici, Founder & Lead Developer
Formula
Output = 4 × ceil(InputBytes / 3) | Size Overhead = 33.3%
Base64 converts every 3 bytes of input into 4 ASCII characters using a 64-character alphabet. This produces a predictable 33.3% size increase. Padding characters (=) are added when the input length is not a multiple of 3 bytes.
Worked Examples
Example 1: Encoding an API Key for HTTP Basic Auth
Problem:Encode the credentials 'admin:secretPassword123' for use in an HTTP Basic Authentication header.
Solution:Input: 'admin:secretPassword123' Bytes: 22 characters × 1 byte each = 22 bytes Base64 groups: ceil(22/3) = 8 groups → 32 characters Encoded: YWRtaW46c2VjcmV0UGFzc3dvcmQxMjM= Padding: 1 '=' character (22 mod 3 = 1, needs 2-byte padding → 1 '=') HTTP Header: Authorization: Basic YWRtaW46c2VjcmV0UGFzc3dvcmQxMjM= Size overhead: 32 bytes vs 22 bytes = 45.5% increase
Result:YWRtaW46c2VjcmV0UGFzc3dvcmQxMjM= (32 chars, +45.5% overhead)
Example 2: Decoding a JWT Token Payload
Problem:Decode the URL-safe Base64 payload: eyJ1c2VyIjoiam9obiIsInJvbGUiOiJhZG1pbiIsImlhdCI6MTcwMDAwMDAwMH0
Solution:Input (URL-safe Base64): eyJ1c2VyIjoiam9obiIsInJvbGUiOiJhZG1pbiIsImlhdCI6MTcwMDAwMDAwMH0 Convert to standard: replace - with +, _ with / Add padding: length 63, needs 1 '=' → eyJ1c2VyIjoiam9obiIsInJvbGUiOiJhZG1pbiIsImlhdCI6MTcwMDAwMDAwMH0= Decoded: {'user':'john','role':'admin','iat':1700000000} Original size: 47 bytes | Encoded size: 64 chars
Result:{'user':'john','role':'admin','iat':1700000000}
Frequently Asked Questions
What is Base64 encoding and why is it used?
Base64 is a binary-to-text encoding scheme that represents binary data using a set of 64 printable ASCII characters (A-Z, a-z, 0-9, +, /). It was designed to safely transmit binary data through systems that only support text, such as email (MIME), HTML, CSS, URLs, and JSON. Without Base64, binary data like images, files, or encrypted content could be corrupted during transmission because certain byte values have special meanings in text-based protocols. Base64 converts every 3 bytes of binary data into 4 Base64 characters, resulting in approximately 33% size increase. Despite this overhead, it is essential for embedding images in HTML (data URIs), transmitting attachments in email, encoding authentication credentials in HTTP headers (Basic auth), and storing binary data in JSON or XML documents. The encoding is reversible, meaning the original binary data can be perfectly reconstructed from the Base64 string.
How does Base64 encoding work internally?
Base64 encoding works by converting binary data in groups of 3 bytes (24 bits) into 4 Base64 characters (6 bits each). The process involves: (1) Take 3 bytes of input, forming 24 bits. (2) Split these 24 bits into four 6-bit groups. (3) Map each 6-bit value (0-63) to a character from the Base64 alphabet: A-Z (0-25), a-z (26-51), 0-9 (52-61), + (62), / (63). If the input length is not a multiple of 3, padding characters (=) are added: one byte of input produces 2 Base64 characters plus '==', two bytes produce 3 characters plus '=', and three bytes produce 4 characters with no padding. For example, the text 'Hi' (2 bytes: 0x48 0x69) becomes binary 01001000 01101001, padded to 010010 000110 100100, which maps to S, G, k with one padding, giving 'SGk='. Understanding this mechanism helps debug encoding issues and estimate output sizes.
What is the difference between standard Base64 and URL-safe Base64?
Standard Base64 (RFC 4648 Section 4) uses the characters A-Z, a-z, 0-9, +, and / with = for padding. However, the + and / characters have special meanings in URLs (+ represents a space, / is a path separator), making standard Base64 strings problematic when used in URLs or filenames. URL-safe Base64 (RFC 4648 Section 5) addresses this by replacing + with - (hyphen) and / with _ (underscore), and typically omitting the = padding characters since the decoder can infer padding from the string length. URL-safe Base64 is commonly used in JWT (JSON Web Tokens), URL parameters, cookie values, and filename-safe encodings. Some implementations call this 'base64url'. When decoding, it is important to know which variant was used for encoding, as mixing them will produce incorrect results. Most programming languages offer both variants in their standard libraries.
What is the size overhead of Base64 encoding?
Base64 encoding increases data size by exactly 33.33% (4/3 ratio) for the raw encoding, plus potential padding overhead. For every 3 bytes of input, 4 bytes of Base64 output are produced. The exact output size can be calculated as: Output = 4 × ceil(InputBytes / 3). For practical purposes: a 1 KB file becomes approximately 1.37 KB in Base64, a 1 MB image becomes about 1.37 MB, and a 10 MB video becomes roughly 13.3 MB. When Base64 is used in text formats like JSON or XML, there may be additional overhead from escaping characters and wrapping in quotes. Some implementations add line breaks every 76 characters (as specified in MIME), which adds further overhead. This size increase is why Base64 should not be used for large file transfers — dedicated binary protocols are more efficient. However, for small to medium data like icons, thumbnails, and authentication tokens, the convenience outweighs the size penalty.
When should I avoid using Base64 encoding?
While Base64 is useful in many scenarios, there are situations where it should be avoided. First, do not use Base64 for encrypting or securing data — it is an encoding scheme, not encryption, and anyone can decode it instantly. Never Base64-encode passwords or sensitive data thinking it provides security. Second, avoid embedding large files as Base64 in HTML or CSS because it increases page size by 33%, cannot be cached separately, and blocks rendering. Images larger than a few kilobytes should be served as separate files. Third, do not use Base64 for binary-to-binary transfers where protocols already support binary data (like WebSockets in binary mode, gRPC, or direct file uploads). Fourth, avoid Base64 in database storage when the database supports BLOB types natively, as it wastes storage space. Fifth, for API responses returning large binary data, consider using multipart responses or direct file downloads instead of Base64-encoded JSON fields. The general rule is to use Base64 only when your transport medium requires text-only data.
References
Background & Theory
History
Reviewed for accuracy by Daniel Agrici, Founder & Lead Developer · Editorial policy
Related Calculators
🧮Base64 Encoder Decoder
Calculate base64 encoder decoder with inputs, formulas, and instant results.
🧮Base64 Encode Decode Tool
Encode text to Base64 or decode Base64 strings back to plain text instantly.
🧮URL Encode Decode Tool
Encode special characters for URLs or decode percent-encoded URL strings.
🧮Html Entity Encoder
Calculate html entity encoder with inputs, formulas, and instant results.
🧮Jwt Decoder
jwt decoder. Get instant, accurate results.
🌐URL Encoder
Encode and decode URLs