Skip to main content

Base64 encode Decode Calculator

Free Base64encode decode Calculator for encoding & hash. Enter parameters to get optimized results with detailed breakdowns.

Skip to calculator
Computer & IT

Base64encode Decode Calculator

Encode text to Base64 or decode Base64 strings instantly. Supports standard and URL-safe Base64 with size analysis, character breakdown, and hex output.

Last updated: December 2025

Calculator

Adjust values & calculate
Understand the Math

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.

Last reviewed: December 2025

Worked Examples

Example 1: Encoding an API Key for HTTP Basic Auth

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

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}
Expert Insights

Background & Theory

The Base64encode Decode Calculator applies the following established principles and formulas. Computers represent all information using binary, a base-2 number system consisting solely of the digits 0 and 1, each called a bit. Because long binary strings are unwieldy, programmers routinely use octal (base 8) and hexadecimal (base 16) as compact shorthand. Converting between bases follows a consistent algorithm: divide the source number repeatedly by the target base, collecting remainders in reverse order. Hexadecimal digits A through F represent the values 10 through 15, allowing a single character to encode four binary bits, making it the preferred notation for memory addresses, color codes, and bytecode. Bitwise operations manipulate individual bits within integers. AND produces a 1 only when both input bits are 1, making it useful for masking. OR produces a 1 when either bit is 1 and is used for combining flags. XOR flips bits that differ, enabling simple toggle logic and efficient swap algorithms. NOT inverts every bit (one's complement), while left and right shifts multiply or divide by powers of two in constant time. Data storage units ascend in binary multiples of 1024: 8 bits form one byte, 1024 bytes form one kibibyte (KiB), 1024 KiB form one mebibyte (MiB), and so forth. Hard-drive manufacturers historically use decimal prefixes (1 KB = 1000 bytes), creating the persistent confusion between binary and decimal interpretations of the same label. The IEC standardized the binary prefixes KiB, MiB, GiB, and TiB in 1998 to resolve this ambiguity. Network bandwidth is measured in bits per second (bps), most commonly megabits per second (Mbps) or gigabits per second (Gbps). A 100 Mbps connection transfers 100 million bits every second, equating to roughly 12.5 megabytes per second. IP subnet masks define network boundaries; CIDR notation appends a prefix length (e.g., /24) to an address, indicating how many leading bits are fixed. A /24 subnet contains 256 addresses with 254 usable hosts. Algorithm efficiency is described using Big-O notation, which characterises the worst-case growth of time or space relative to input size. O(1) is constant, O(log n) is logarithmic (binary search), O(n) is linear, and O(n²) is quadratic. Cryptographic hash functions like SHA-256 produce a fixed 256-bit (32-byte) digest regardless of input length. File compression algorithms exploit statistical redundancy to reduce storage footprint, and compression ratio equals the original file size divided by the compressed size.

History

The history behind the Base64encode Decode Calculator traces back through the following developments. The conceptual foundation of modern computing traces back to Charles Babbage, whose Analytical Engine design of 1837 introduced the idea of a general-purpose mechanical computer with separate storage and processing units, including what he called the Store and the Mill. Ada Lovelace wrote what many consider the first algorithm intended for machine execution while annotating a translation of Luigi Menabrea's account of Babbage's work, also recognising the machine's potential to manipulate symbols beyond mere numbers. George Boole published "The Laws of Thought" in 1854, formalising a two-valued algebra of logic that would later map perfectly to electrical circuits. It remained largely a mathematical curiosity until Claude Shannon's landmark 1937 master's thesis demonstrated that Boolean algebra could describe switching circuits, laying the theoretical groundwork for all digital electronics. Shannon's 1948 paper "A Mathematical Theory of Communication" defined the bit as the fundamental unit of information and established information theory as a rigorous discipline. The same year, the transistor was invented at Bell Labs by Bardeen, Brattain, and Shockley, eventually replacing vacuum tubes and enabling miniaturisation at scale. ENIAC, completed in 1945, was one of the first general-purpose electronic computers, occupying 1800 square feet and consuming 150 kilowatts of power while performing roughly 5000 additions per second. The ASCII standard was ratified in 1963, assigning 7-bit codes to 128 characters and enabling interoperability between computers from different manufacturers. Through the 1970s, the microprocessor consolidated an entire CPU onto a single chip; Intel's 4004 in 1971 marked the beginning of this trend. The Apple II launched in 1977 and the IBM PC in 1981 brought computing to homes and offices, triggering a mass-market software industry. Tim Berners-Lee proposed the World Wide Web in 1989 and launched the first website in 1991 at CERN, transforming the internet from an academic and military network into a global information infrastructure. Mobile computing accelerated through the 2000s with smartphones integrating powerful processors, wireless networking, and GPS into pocket-sized devices, extending computation into every facet of daily life and cementing TCP/IP as the universal communications fabric.

Share this calculator

Explore More

Frequently Asked Questions

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.
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.
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.
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.
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.
You may use the results for reference and educational purposes. For professional reports, academic papers, or critical decisions, we recommend verifying outputs against peer-reviewed sources or consulting a qualified expert in the relevant field.
Educational Note: This calculator is provided for educational and informational purposes. Results are based on the formulas and inputs provided. Always verify important calculations independently. NovaCalculator processes calculator inputs client-side; optional analytics follow visitor consent settings. © 2024–2026 NovaCalculator.

Share this calculator

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'\nBytes: 22 characters × 1 byte each = 22 bytes\nBase64 groups: ceil(22/3) = 8 groups → 32 characters\nEncoded: YWRtaW46c2VjcmV0UGFzc3dvcmQxMjM=\nPadding: 1 '=' character (22 mod 3 = 1, needs 2-byte padding → 1 '=')\nHTTP Header: Authorization: Basic YWRtaW46c2VjcmV0UGFzc3dvcmQxMjM=\nSize 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\nConvert to standard: replace - with +, _ with /\nAdd padding: length 63, needs 1 '=' → eyJ1c2VyIjoiam9obiIsInJvbGUiOiJhZG1pbiIsImlhdCI6MTcwMDAwMDAwMH0=\nDecoded: {'user':'john','role':'admin','iat':1700000000}\nOriginal 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.

Can I use Base64 encode Decode Calculator on a mobile device?

Yes. All calculators on NovaCalculator are fully responsive and work on smartphones, tablets, and desktops. The layout adapts automatically to your screen size.

References

Reviewed by Daniel Agrici, Founder & Lead Developer · Editorial policy