Base64 Text & File Encoder/Decoder: Conversions

Convert bytes to Base64 characters

How to convert bytes to Base64 characters

Calculating Base64 output size requires the 3-to-4 byte-to-character ratio. Divide your byte count by 3, round up to the nearest whole number, then multiply by 4. Each group of 3 input bytes produces exactly 4 Base64 characters; incomplete groups at the end pad to a full 4-character block using = signs.

Common bytes to Base64 characters conversions

Why Base64 expands data by 33%

Base64 uses 64 printable characters to represent any byte value. Six bits of input encode one Base64 character, which means 3 bytes (24 bits) produce exactly 4 characters (24 ÷ 6 = 4).¹ Consequently, every 3 bytes become 4 characters , a factor of 4/3 ≈ 1.333.² For a 300-byte JSON body, this overhead adds 100 extra characters to the payload. Building on this, the expansion is constant regardless of data content; the algorithm treats all bytes identically, so text files gain no advantage over binary files.

Applying the 3-to-4 ratio

Use the ratio before you send a request or embed a file in HTML. Multiply the byte count by 4, divide by 3, and round up to the nearest whole number. The result is the number of Base64 characters before any line wrapping. For example, a 1,500-byte profile thumbnail encodes to exactly 2,000 Base64 characters, which means you can quickly verify whether a given payload fits within a database column or API field limit before you attempt the actual encoding operation.

This matters because the check is nearly free: a multiplication beats a full encode-and-measure cycle, and catching an oversized payload at the planning stage avoids a rejected request after the encoding work is already done. The alternative is to encode first and discover the limit only when the gateway rejects the finished payload, which wastes both client and server effort on a request that was doomed before it started.

How padding affects size calculations

Padding matters when input length is not divisible by 3, because the encoder must fill incomplete blocks to maintain the 4-character group structure. One leftover byte produces 2 Base64 characters plus == padding. Two leftover bytes produce 3 Base64 characters plus = padding. In both cases the block still occupies 4 characters.³ Stripping padding saves 0, 1, or 2 characters per string but changes nothing about the decoded byte count. Furthermore, padding-free Base64 is common in JWTs and URL parameters, so Math.ceil(b / 3) * 4 models padded output; subtract the padding count for stripped output.

Accounting for padding

The formula gives the full block count including padding characters. If your protocol strips padding, subtract 0, 1, or 2 characters after calculating the padded length. Do not subtract padding from the decoded byte count. A practical way to handle this in code is to always compute the padded length first, then conditionally strip the trailing = signs based on the target protocol, rather than trying to account for padding in the initial multiplication, which introduces off-by-one errors that are difficult to catch in testing.

Practical size budgeting for APIs and browsers

Browser data URIs are constrained by both URL length limits and DOM memory, because the browser must hold the entire encoded string in memory while rendering.⁴ Embedding a 100 KB PNG as a data URI produces roughly 133 KB of Base64 text.⁵ API gateways like AWS API Gateway cap payloads at 10 MB; your binary file must be under 7.5 MB before encoding to stay within that limit. Because the 4/3 multiplier applies at every scale, a 500 KB certificate file becomes 667 KB of Base64, worth checking before building a config-file embed pipeline. Verifying that a payload fits within API gateway limits before you attempt the upload prevents wasted encoding work and avoids the frustrating situation where a long encoding step completes successfully only to be rejected by the gateway because the encoded output exceeds the maximum allowed request size.

Planning before upload

Estimate the encoded size before you build the request body. A field name, JSON quotes, and transport headers add more characters, so leave headroom below the documented limit. A good practice is to reserve at least 20% of the documented limit for encoding overhead and metadata, because a payload that fits at exactly the limit in raw bytes will exceed it once Base64 encoding expands the data and the JSON structure adds field names, quotes, and commas around the encoded value.

Estimating output size for API request bodies

When building an API request that carries Base64-encoded binary data, calculate the encoded character count before constructing the request body to avoid rejected payloads. Multiply your byte count by 4/3 and round up to the nearest multiple of 4. A 1,500-byte thumbnail encodes to Math.ceil(1500 / 3) * 4 = 2,000 characters. Adding the field name, quotes, and JSON structure overhead puts the full request body near 2,100 characters, well within the 10 MB limit most API gateways enforce.

For batch APIs that accept arrays of Base64-encoded items, estimate total payload size before sending the request. Ten 50 KB images encode to approximately 682,672 characters (about 668 KB). Compare this figure against the server's documented limit before attempting the request, to avoid a rejected payload after a long encoding step that wastes both client and server resources.

For everyday encoding tasks

A few reference values anchor the formula for common scenarios. A 128-bit AES key (16 bytes) encodes to 24 Base64 characters. A 256-bit key (32 bytes) encodes to 44 characters. A UUID stored as raw binary (16 bytes) produces 24 characters; as the hyphenated string (36 bytes of UTF-8) it encodes to 48 characters. An RSA-2048 signature is 256 bytes, producing 344 Base64 characters.

Knowing these reference lengths helps you catch encoding mistakes before they reach a parser. A JWT header claiming RS256 should produce a 344-character Base64 signature. A signature that arrives as 340 or 348 characters is either truncated or padded incorrectly. Validate lengths as a quick sanity check before attempting cryptographic verification.¹

Try in the tool

Convert Base64 characters to bytes

How to convert Base64 characters to bytes

You can recover decoded bytes from a Base64 string by reversing the 3-to-4 character ratio. Multiply the character count by 3, then divide by 4 and floor to a whole number. Padding characters (=) do not affect the result , they signal the last block boundary but each occupied position still carries data.

Common Base64 characters to bytes conversions

Why Base64 expands data by 33%

From the encoded side, the relationship is simple: 4 Base64 characters hold the data of 3 bytes.¹ Decoding reverses the 3-to-4 ratio by multiplying character count by 3/4. Consequently, a 1,000-character Base64 string holds 750 bytes of binary data. Building on this, the relationship is exact when input length is a multiple of 4; otherwise, the floor operation discards the fractional byte that corresponds to padding.

Reversing the encoding ratio

Use the inverse ratio before allocating buffers or checking API response sizes. Count only the Base64 characters, not surrounding JSON quotes, field names, or MIME line breaks. A common mistake is to measure the entire JSON field value including the quotes and field name, which inflates the character count and leads to an overestimated buffer allocation that wastes memory or triggers unnecessary size-limit rejections on the server side.

This matters because over-allocation is the quieter failure: it does not crash, it just quietly raises the memory footprint of every request, so a service that allocates generously on every decode slowly costs more than one that measures the data characters only. Across millions of requests the wasted headroom adds up to real memory and dollar cost, while a tight allocation sized from the true character count keeps each decode lean.

How padding affects size calculations

Padding characters (=) occupy positions in the 4-character block but do not encode new bytes beyond what the data characters already carry. A Base64 string ending in == means the final block holds 1 decoded byte, not 2. Stripping padding before counting characters causes the formula to undercount by 1 or 2 bytes. Conversely, Math.floor(c * 3 / 4) handles stripped padding only when applied to the character count before stripping.² Use the original padded length for accurate results.

Counting before stripping padding

If a string is unpadded, the same floor formula still works on the character count, but the final block may be partial and the result reflects only the data-bearing characters. Add padding only when a strict decoder requires it, not because the size formula needs it. The key insight is that padding is a transport concern, not a data concern: the bytes encoded in the non-padding characters carry all the information, and the = signs only tell the decoder how to interpret the final incomplete block, so stripping them before measuring for size calculations gives you the true data-bearing character count.

Practical size budgeting for APIs and browsers

When an API returns Base64-encoded payloads, knowing the decoded byte count lets you allocate buffers correctly. A 1,333-character Base64 response decodes to exactly 1,000 bytes of binary data. Browser environments have practical limits , decoding a 10 MB Base64 string (13.3 million characters) creates a 10 MB byte array in memory. Furthermore, URL-safe Base64 without padding still follows the same 3/4 ratio; just count only the non-= characters for a correct estimate.

Allocating buffers safely

Use the decoded size as a guardrail before allocating memory. If the estimate approaches a platform limit, reduce the input, stream the decode, or reject the payload before work starts. In serverless environments like AWS Lambda where memory is allocated in fixed increments, estimating the decoded size accurately lets you choose the smallest memory configuration that handles your expected payload range, which directly reduces cost because Lambda pricing scales linearly with allocated memory.

Checking decoded size before allocation

Checking the decoded byte count before allocating memory helps avoid out-of-memory conditions when handling large Base64 inputs from untrusted sources. For a pre-allocation check without decoding, apply the formula directly: bytes_count = Math.floor(charCount * 3 / 4), subtracting 1 for each trailing = character. This pattern suits constrained environments such as embedded systems, serverless functions with strict memory limits, and mobile applications where heap allocation causes noticeable performance pauses.

For very long strings, avoid decoding the full payload just to measure its size. Count characters modulo 4 to determine padding and apply the floor calculation. The decoded byte count is deterministic from the character count alone, so pre-allocation calculations are always safe to compute before the decode step, and they prevent a malicious client from triggering excessive memory allocation through a carefully crafted Base64 input.

Chunked streaming and block alignment

When streaming Base64 data through a network connection or file read, always read chunks in multiples of 4 characters. A chunk boundary that lands mid-block leaves an incomplete Base64 group that decodes to wrong bytes or triggers a padding error.¹ For network streaming, a read buffer of 4,096 characters (1,024 complete blocks) decodes to exactly 3,072 bytes with no alignment overhead.

Chunked decoding appears in HTTP multipart responses, large file downloads piped through a Base64 encoder, and server-sent event streams carrying binary payloads. In all of these cases, the 4-character block boundary is the critical invariant. Cross it and the decoder produces corrupted output silently in many libraries. Check your chunk size before building any streaming Base64 pipeline.

Reference sizes for common data types

For common data types, the decoded sizes map predictably from character counts, which helps you validate encoded values before decoding them. A 44-character Base64 string (with == padding) decodes to 32 bytes, which is a SHA-256 hash.³ A 24-character string decodes to 16 bytes with == padding, the length of a raw UUID.⁴ An RSA-2048 private key in PKCS#8 DER format produces roughly 1,704 Base64 characters, decoding to about 1,278 bytes.⁵

Knowing these reference values helps you spot truncation bugs at a glance. A SHA-256 hash presented as 64 characters is hex-encoded, not Base64. An unexpected 40-character string where a 44-character SHA-256 hash is expected is missing 4 characters. Character count alone is a fast sanity check before passing decoded data to a cryptographic function.

Try in the tool

Convert kilobytes to Base64 kilobytes

How to convert kilobytes to Base64 kilobytes

A 1.333 multiplier turns raw kilobytes into a quick Base64 size estimate. Multiply your kilobyte count by 1.333 to get the approximate encoded size. The result rounds to 3 decimal places. For exact byte-level precision, use the bytes-to-Base64-characters formula instead.

Common kilobytes to Base64 kilobytes conversions

Why Base64 expands data by 33%

At kilobyte scale, Base64 maps 3 input bytes to 4 output characters, producing a 4/3 ratio that compounds quickly with larger files.¹ 1 KB (1,024 bytes) encodes to approximately 1,366 Base64 characters, or 1.365 KB. The 1.333 multiplier is a practical approximation valid to within 0.25% for inputs larger than 100 bytes.² Consequently, a 5 MB file becomes roughly 6.67 MB as Base64, making this estimate useful for browser payload limits, CDN cache sizing, and API quota planning.

Using the multiplier

Use 1.333 when you need a quick budget estimate during design discussions. Use the exact 4/3 formula when the receiver enforces a strict byte or character limit that you must not exceed. The quick multiplier is particularly useful during architecture reviews and capacity planning meetings, where you need to estimate whether a proposed file upload feature will fit within existing API gateway limits without pulling up a calculator for every scenario.

This matters because the estimate is good enough to say no to a design before it ships, even if it is not exact enough to validate a strict byte limit, and using the quick number in the room keeps the planning conversation moving instead of stalling on arithmetic. A rough ceiling caught early is far more useful than a precise figure produced after the upload feature is already built and harder to change.

How padding affects size calculations

Padding adds 0, 1, or 2 = characters depending on whether the original file size is divisible by 3. For large files, padding contributes at most 2 characters , negligible at kilobyte scale. The 1.333 multiplier absorbs this rounding. Stripping padding saves 0–2 bytes per file, which does not change the kilobyte-level estimate.³ Building on this, the approximation is conservative: the true factor for a 1,024-byte block is 4/3 × 1024 / 1024 = 1.3333..., so results are accurate to 3 decimal places.

Ignoring tiny rounding differences

Do not let padding dominate a kilobyte estimate. For small files, switch to the exact formula; for larger files, the multiplier is enough for planning. The difference between 1.333 and the exact 4/3 ratio amounts to less than 1 KB per 3 MB of input data, which is well within the margin of error for any real-world capacity estimate where network overhead, protocol headers, and database storage alignment introduce far larger uncertainties than the Base64 rounding.

Practical size budgeting for APIs and browsers

Estimating encoded size at kilobyte scale requires accounting for both the 4/3 expansion ratio and the overhead that JSON structure, transport headers, and protocol limits add to the final payload, because a file that fits in raw bytes will exceed the limit once these factors combine. Browser data URI size limits vary by engine, and exceeding them causes silent rendering failures.⁴ Chromium supports data URIs up to 2 MB, so images must stay below 1.5 MB before encoding.⁵ AWS API Gateway limits request payloads to 10 MB with base64 enabled, meaning binary payloads must be under 7.5 MB to leave room for encoding overhead. Because the multiplier applies at any scale, planning a batch pipeline that processes 1,000 files averaging 50 KB each produces roughly 66.7 MB of Base64, worth factoring into storage and transfer cost before you build.

Cloud storage and database overhead

When you plan for cloud storage, remember that the 1.333 multiplier also applies to the stored size of Base64-encoded values in environment variables, configuration files, and database text columns. A service that stores 10,000 Base64-encoded API keys, each representing 32 bytes of random data, uses approximately 533 KB of text storage instead of the 320 KB that binary storage would require, a difference that matters at scale when billing is per-gigabyte.

File type examples across the 1.333 multiplier

File type shapes how much the 1.333 multiplier costs you in practice. JPEG photos are already compressed: a 200 KB JPEG becomes 266 KB as Base64. Uncompressed PNGs scale harder because they carry raw pixel data; a 500 KB PNG becomes 666 KB. PDF documents that embed fonts and vector graphics often compress well with GZIP before encoding: a 1 MB PDF that GZIPs to 400 KB encodes to 532 KB as Base64, well inside most API limits.

For video thumbnails, keeping the source JPEG under 50 KB produces a 66.5 KB Base64 string that fits comfortably in a JSON field without triggering payload size limits. API gateways typically reject Base64 payloads above 10 MB, so plan your raw file size at a 7.5 MB ceiling to guarantee headroom.

In storage and bandwidth cost planning

Storage costs compound quickly when you store Base64 strings instead of binary BLOBs in a database. A database storing 100,000 user avatars as Base64 strings instead of binary values carries an additional 33 KB overhead for every 100 KB of image data. Binary BLOB columns in MySQL, PostgreSQL, and SQLite handle arbitrary byte sequences natively; Base64 string columns belong in configuration files and API transport contexts, not in primary storage. The 33% overhead applies to every Base64 value in the database, so for a table with several Base64 columns, the total storage impact multiplies across each column and each row, which can significantly increase the database size and slow down full-table scans that must decode every value.

For CDN delivery, Base64-inlined assets travel in the document body on every uncached page load. Switching a 50 KB Base64 icon to an external CDN reference saves 66.5 KB per uncached request. Multiply that saving across your monthly page view count to calculate the concrete bandwidth reduction. Over a high-traffic site with millions of monthly page views, this per-request saving compounds into a meaningful reduction in total bandwidth consumption and the associated infrastructure cost.

Setting inlining thresholds in build pipelines

Setting an inlining threshold in your build tool determines which assets the compiler embeds as Base64 and which it serves as external references. Webpack's url-loader defaults to 8 KB; Vite uses 4 KB through its assetsInlineLimit option. A 5 KB icon becomes a 6.65 KB Base64 string in your bundle. An icon of exactly 8 KB (the maximum for the default Webpack threshold) adds 10.66 KB to your JavaScript bundle.

Run your production build and check the bundle size report before finalising the threshold. Raise the threshold in 2 KB increments and measure the page load time impact at each step. The right threshold balances the latency savings from eliminating HTTP requests against the parse cost of larger JavaScript files.¹

Try in the tool