Base64 is a scheme for encoding binary data as text using 64 ASCII characters. In web development, it is used to embed images in HTML/CSS, transfer files in JSON, and store binary data in text-based protocols. This article covers how it works, its use cases, and potential pitfalls.
Use the Base64 Encoder on reChecker to encode and decode Base64.
How Base64 works
The principle
Data is divided into blocks of 3 bytes (24 bits). Each block is encoded as 4 characters from the alphabet: A–Z, a–z, 0–9, +, /. The = character is used for padding when the original size is not a multiple of 3.
Исходные байты: [01001000] [01100101] [01101100]
↓
Base64: S G V sSize
Base64 increases data size by about 33%: 3 bytes become 4 characters. An image of 10 KB becomes about 13.3 KB.
| Original size | Base64 size |
|---|---|
| 1 KB | ~1.37 KB |
| 10 KB | ~13.3 KB |
| 100 KB | ~133 KB |
Uses on the web
Data URIs in HTML and CSS
Embedding images directly in markup or styles:
<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUA..." alt="Иконка">.hero {
background: url('data:image/jpeg;base64,/9j/4AAQSkZJRgABAQAA...') center/cover;
}Pros: no separate HTTP request, and the content is available immediately. Cons: larger HTML/CSS files and no caching separately from the page.
Transferring files in JSON
APIs often do not support binary data directly. Base64 lets you send a file in a JSON field:
{
"filename": "document.pdf",
"content": "JVBERi0xLjQKJeLjz9MK..."
}The server decodes the string and saves it as a file.
Basic authentication
The Authorization header with a username and password:
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=The username:password string is encoded in Base64. Important: Base64 is not encryption. The data can be easily decoded. Use it only over HTTPS.
Storing data in localStorage/sessionStorage
These APIs accept strings only. Base64 is used to store binary data (for example, a small image).
When to use Base64
Suitable use cases
| Use case | Reason |
|---|---|
| Critical icons (favicon, header logo) | Eliminates a request and speeds up First Paint |
| Very small images (< 2 KB) | The overhead of a request exceeds the Base64 overhead |
| Dynamic generation (CAPTCHA, QR code) | The data is already in memory, so embedding it makes sense |
| Email newsletters | Inline images as attachments for better delivery |
Unsuitable use cases
| Use case | Problem |
|---|---|
| Large images (> 10 KB) | Larger size, blocked rendering, no caching |
| Many small icons | A sprite or SVG sprite is more efficient |
| Content that changes infrequently | Caching a separate file is more efficient |
| Critical CSS | Increases the size of a render-blocking resource |
Limitations and pitfalls
URL length
Browsers and servers limit URL length (often 2–8 KB). Long Data URIs in url() may not work in older browsers. Use Blob URLs or separate files for large data.
Caching
An embedded image is cached only along with the page or CSS file. If one icon is updated, the user has to download the entire updated resource again.
Gzip/Brotli
Text formats (HTML, CSS, JS) are compressed. Base64 strings inside them compress poorly because they are already a compressed representation of binary data. A separate binary file (PNG, JPEG) compresses better during transfer.
Security
Base64 does not provide confidentiality. Do not encode passwords or tokens “for security”—this is not encryption.
Working with Base64 in code
JavaScript: encoding
// Строка в Base64
btoa('Hello, World!'); // "SGVsbG8sIFdvcmxkIQ=="
// Unicode: сначала encodeURIComponent
btoa(encodeURIComponent('Привет')); // "JUUwJUJDJUJFJUUwJUI4JTgxJUUwJUI4JUI0"JavaScript: decoding
atob('SGVsbG8sIFdvcmxkIQ=='); // "Hello, World!"
// Unicode
decodeURIComponent(atob('JUUwJUJDJUJF...'));File/Blob to Base64
const file = document.querySelector('input[type=file]').files[0];
const reader = new FileReader();
reader.onload = () => console.log(reader.result); // data:image/png;base64,...
reader.readAsDataURL(file);Node.js
const buffer = fs.readFileSync('image.png');
const base64 = buffer.toString('base64');Practical recommendations
- Size threshold — do not embed images larger than 2–4 KB using Base64
- Criticality — reserve Base64 for resources that block rendering
- Tools — use the Base64 Encoder on reChecker for quick checks and conversions
- Alternatives — consider SVG sprites for icons and lazy loading with separate files for images
- Metrics — check the impact on LCP and document size in DevTools
Base64 is a useful tool when used deliberately. Overuse harms performance; moderate use solves embedding and data-transfer needs.
Base64 alphabet
The standard alphabet (RFC 4648): A-Z, a-z, 0-9, +, /. The = character is used for padding at the end. The Base64url variant (for URLs) replaces + with - and / with _, and removes padding—making it convenient for passing data in query parameters and JWTs.
Length limits in different contexts
| Context | Typical limit |
|---|---|
| URL in a browser | 2–8 KB, depending on the browser |
| CSS url() | Practically unlimited, but large Data URIs block rendering |
| JSON | Depends on the parser, usually up to several MB |
| Email (HTML) | Recommended: up to 10–20 KB per image |
If you exceed these limits, use external files or Blob URLs.
Debugging Base64
If embedded images are not displaying correctly, check that the MIME type is valid (image/png, image/jpeg, image/svg+xml), that the string contains no extra spaces or line breaks, and that it uses the correct encoding (ASCII only). The Base64 Encoder on reChecker shows the size before and after encoding, helping you assess the overhead.
Base64 in Data URIs for SVG
SVG can be embedded without Base64—as “raw” text with special characters escaped:
background: url('data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg">...</svg>');Special characters (#, ?, &) need to be encoded. Base64 avoids this requirement by encoding the entire SVG. For small SVGs, the “raw” version may be more compact; for complex ones, Base64 is easier to maintain.
Comparison with external files
| Criterion | Inline Base64 | External file |
|---|---|---|
| HTTP requests | Fewer | More |
| Caching | Along with HTML/CSS | Separately |
| Size | +33% overhead | Original |
| First render | Faster (no request) | Slower (blocking) |
| Reuse | No | Yes |
The right choice depends on the context. Use inline for small, critical resources; use external files with caching for everything else.