छवि से Base64

How It Works

1. Drop or pick an image. The browser reads the file locally with the FileReader API. Nothing is uploaded anywhere.
2. The encoder converts the bytes using the standard Base64 alphabet, every 3 input bytes become 4 ASCII characters drawn from A-Z a-z 0-9 + /, with up to two trailing = padding characters when the input length isn't a multiple of 3.
3. Copy what you need. "Copy Base64" gives you just the encoded string (useful for JSON payloads or backend processing). "Copy Data URI" gives you the full data:image/png;base64,… form ready to drop into an <img src> attribute or a CSS background-image: url(…).
4. Paste it where it belongs. The output is plain text, works in HTML, CSS, JSON, JavaScript, Markdown, or anywhere else a string can live.

What Base64 Actually Does

Base64 is defined in RFC 4648 (October 2006). The encoding takes 24 bits of input at a time (three bytes) and rewrites them as four 6-bit indexes into a 64-character alphabet. The math is exact: 3 bytes (24 bits) → 4 characters (each carrying 6 bits). When the input length isn't a multiple of 3, the encoder appends = padding characters to make the output length a multiple of 4.

Two practical consequences:

• Output is always ~33% larger than input. The 4/3 ratio is fundamental to the algorithm. A 100 KB image becomes ~133 KB Base64. With MIME-style 76-character line breaks the overhead is closer to 37%.
• Output is text-safe everywhere. The 64-character alphabet is the intersection of every common ASCII text channel, HTML, JSON, XML, e-mail, URLs (with the URL-safe variant), source code. That is the entire reason Base64 exists: to move binary data through systems that were designed for text.

RFC 4648 §12 spells out one important non-feature: "Base64 encoding visually hides otherwise easily recognized information, such as passwords, but does not provide any computational confidentiality." Anyone can decode a Base64 string in two lines of code in any language. It is encoding, not encryption.

Data URIs: the Inline-Image Form

A "data URI" is the wrapper format that lets a Base64 string take the place of an image URL. RFC 2397 (1998) defines the syntax:

data:[<mediatype>][;base64],<data>

For images, that means data:image/png;base64,iVBORw0KGgo… in an <img src> attribute or background-image: url("data:image/svg+xml;utf8,<svg…>") in CSS. The ;base64 token tells the browser the data part is encoded; without it, the data is taken as percent-encoded text. RFC 2397 itself notes that data URIs are "only useful for short values", a hint that has aged into a hard performance rule.

When You Should Inline an Image as Base64

• Single-file artefacts. An e-mail signature with an embedded logo that needs to survive forwarding. A self-contained HTML demo for CodePen, JSFiddle, or a bug-report repro. A generated PDF where the image must be embedded so the file works offline.
• Tiny critical-path icons. A 200-byte chevron or loading spinner inlined into critical CSS may load faster than triggering a separate HTTP request, especially on slow connections.
• Inline JSON / API responses. Avatar uploads, signatures, OCR samples, generated QR codes, anything where the API consumer expects the bytes inline rather than a separate URL to fetch.
• Sandboxed iframes or other contexts that prohibit external resource loading.
• Configuration files where you don't want a sibling image file alongside the JSON / TOML / YAML.

When You Should Not Inline an Image as Base64

For most production websites, an inlined Base64 image is slower than a normal <img> reference. Five compounding reasons:

1. 33% size overhead, always. Every byte costs 4/3 bytes after encoding. Once gzip is applied the apparent overhead shrinks (because Base64 is repetitive), but the bytes the browser parses are still 33% larger than the original.
2. The image cannot be cached separately. An external image.png is fetched once and reused on every page that links to it. A Base64 image lives inside the HTML or CSS and is re-downloaded with every change to that file.
3. Slows HTML and CSS parsing. Long inlined strings inside render-blocking CSS push the critical path further out. Harry Roberts (CSS Wizardry) measured a real client stylesheet at 925 KB with Base64 images vs 708 KB without, and 232 KB gzipped vs 68 KB. Removing Base64 cut the gzipped CSS by 70.68%.
4. Cannot be lazy-loaded. The loading="lazy" attribute defers fetching an image until the user scrolls near it. Base64 images are already in the document, there is nothing to defer.
5. HTTP/2 and HTTP/3 already solved the "too many requests" problem. Multiplexing lets a single connection deliver hundreds of files in parallel, so the original justification for inlining is mostly gone.

A practical rule of thumb from Google's PageSpeed and most performance writers: inline only if the image is under ~1–2 KB encoded, and only if it appears above the fold in critical CSS. Anything larger almost certainly performs better as a separate file.

SVG: Use UTF-8 Encoding, Not Base64

SVG is text already, so encoding it as Base64 wastes ~33% of bytes for no benefit. The smaller form is URL-encoded UTF-8:

/* Base64 SVG (longer) */
background-image: url("data:image/svg+xml;base64,PHN2ZyB4bWxucz0i…");

/* URL-encoded SVG (shorter, also human-readable) */
background-image: url("data:image/svg+xml;utf8,<svg xmlns='http://www.w3.org/2000/svg' …>");

Most modern build tools (PostCSS' postcss-inline-svg, Webpack's svg-url-loader) emit the URL-encoded form by default. For inline SVG, prefer that form over Base64 unless a specific consumer requires ;base64.

MIME Types This Tool Recognises

The data URI's media-type prefix is what tells the consumer how to interpret the bytes. The browser detects it from the file you pick:

Privacy and Security Notes

Most online "image to Base64" sites upload your file to their server, encode there, and serve the result back. That means screenshots of pre-release UI, NDA'd designs, photos of children, medical scans, or signatures-on-contracts traverse a third party's infrastructure. This tool encodes locally, the browser's FileReader reads the file into memory, the encoder runs in JavaScript on your device, and the only thing that leaves the page is the encoded string when you copy it.

Two Content Security Policy notes worth knowing if you ship Base64 images in production:

• Inlined Base64 images bypass img-src rules unless you explicitly allow them. A strict CSP like img-src 'self' blocks data: URIs. To allow them, write img-src 'self' data:.
• The same applies to CSS-inlined background images. If a CSP is blocking your inlined backgrounds, check the img-src directive first.

Common Mistakes

1. Treating Base64 as obfuscation. It isn't. Anyone can decode it in two lines of any language. Don't put credentials, API keys, or sensitive data inside Base64 strings "to hide them."
2. Inlining a 200 KB hero image. The image becomes 266 KB encoded, gets stuck inside the HTML, can't be cached separately, can't be lazy-loaded, and the page's first paint is visibly slower. Serve it as a normal file.
3. Copying the raw Base64 when you needed the data URI. A bare Base64 string in an <img src> attribute renders as broken, you need the data:image/png;base64, prefix. Use the "Copy Data URI" button.
4. Base64-encoding SVG. SVG is already text. URL-encode it instead and save the 33% overhead.
5. Forgetting CSP. Strict img-src 'self' blocks data URIs. Add data: to the directive if you ship Base64 images.
6. Trying to decode a Base64 string with a leading data: prefix. The data:image/...;base64, portion is metadata; strip it before passing the string to a Base64 decoder.
7. Pasting confidential images into a server-side encoder. If the URL says "encode" but the network tab shows a POST, your image just left your machine.

Frequently Asked Questions

What's the difference between "Base64" and "Data URI"?

Base64 is the encoding (a string like iVBORw0KGgo…. A Data URI is the wrapper that turns a Base64 string into something that can stand in for an image URL) data:image/png;base64,iVBORw0KGgo…. The wrapper tells the browser the media type and the encoding so it knows how to interpret the bytes. The two buttons in this tool give you each form separately.

Is Base64 secure?

No, and that's not what it's for. Base64 is encoding, not encryption. RFC 4648 §12 puts it directly: it "does not provide any computational confidentiality." Anyone can decode a Base64 string instantly. If you need privacy, encrypt the data first (with AES, etc.) and then Base64 the ciphertext for transport.

How big can the image be?

There's no hard limit imposed by the tool, since encoding happens in your browser's memory. Practical ceiling is whatever your device can hold, typically tens of MB are fine on modern laptops. The bigger constraint is consumer support: many email clients, browsers, and APIs have their own data-URI size limits, and inlining anything over a few KB rarely makes sense for performance.

Why is my Base64 string 33% larger than the file?

Because each Base64 character carries 6 bits, while each input byte carries 8 bits. The smallest unit Base64 can represent without remainder is 3 bytes (24 bits = four 6-bit characters), so the output ratio is exactly 4/3 ≈ 1.33. There's no Base64 variant that avoids this, it's mathematically baked into the encoding.

Will the encoded image work in HTML email?

Mostly, but not always. Apple Mail, modern Gmail, and most webmail clients render data: images cleanly. Microsoft Outlook desktop has historically had inconsistent support, some versions render data URIs fine, others strip them entirely. Test in your target client list before relying on Base64 images in transactional emails. For broad compatibility, hosted image URLs are still the safer bet.

Should I use base64url (with - and _) instead?

Only if you're putting the encoded data in a URL or filename where + and / would otherwise need percent-encoding. For HTML <img src> attributes and CSS background-image values, the standard alphabet works. RFC 4648 §5 defines the URL-safe variant explicitly for those URL/filename cases, and warns it "should not be referred to as only 'base64'" to avoid confusion with the standard alphabet.

संबंधित टूल