Base64 छवि डिकोडर
छवि का पूर्वावलोकन और डाउनलोड करने के लिए Base64 स्ट्रिंग पेस्ट करें।
कैसे उपयोग करें
- पेस्ट करें इनपुट क्षेत्र में Base64-एन्कोडेड छवि स्ट्रिंग। इसमें
data:image/…उपसर्ग शामिल हो भी सकता है और नहीं भी। - पूर्वावलोकन करने के लिए छवि डिकोड करें पर क्लिक करें।
- PNG फ़ाइल के रूप में सहेजने के लिए छवि डाउनलोड करें पर क्लिक करें।
अक्सर पूछे जाने वाले प्रश्न
कौन से Base64 फ़ॉर्मेट समर्थित हैं?
आप कच्ची Base64 स्ट्रिंग (टूल फ़ॉर्मेट को स्वचालित रूप से पता करता है) या एक पूर्ण डेटा URI जैसे data:image/png;base64,iVBOR… पेस्ट कर सकते हैं। समर्थित छवि प्रकार: PNG, JPEG, WebP, GIF, BMP और SVG।
क्या कोई आकार सीमा है?
कोई सख्त सीमा नहीं है, लेकिन आपके डिवाइस के आधार पर बहुत बड़ी Base64 स्ट्रिंग्स (5–10 MB से अधिक) को प्रोसेस करने में समय लग सकता है।
मैं छवि को Base64 में कैसे एन्कोड करूँ?
हमारे छवि से Base64 टूल का उपयोग करें · बस एक छवि को ड्रैग-ड्रॉप करें ताकि उसकी Base64 स्ट्रिंग मिल जाए।
What Base64 actually is
Base64 is a binary-to-text encoding scheme defined in RFC 4648 (October 2006). It uses a 64-character alphabet, A–Z, a–z, 0–9, plus + and /: to represent arbitrary bytes as printable ASCII. Every three bytes of binary input become exactly four characters of output, because the lowest common multiple of 6 bits (one Base64 character) and 8 bits (one byte) is 24. That four-to-three ratio is also why a Base64-encoded file is roughly 33% larger than the original binary.
When the input length isn't a multiple of three, Base64 pads with = so the output is always a multiple of four characters: one trailing byte produces two characters plus ==; two trailing bytes produce three characters plus =. Some encoders strip the padding, so a robust decoder needs to re-pad before passing the string to atob().
RFC 4648 also defines a URL-safe variant (sometimes called base64url) that swaps + for - and / for _. JWTs use it. This decoder normalises both alphabets so you don't have to think about which one you've been handed.
The data URI scheme
RFC 2397 (August 1998) defines the data: URL scheme. The full grammar is:
data:[<mediatype>][;base64],<data>A typical inline PNG looks like data:image/png;base64,iVBORw0KGgo…. The ;base64 token is a marker (note the absence of an = sign) that tells the browser to decode the payload from Base64 instead of treating it as percent-encoded text. If you omit ;base64, the data is interpreted as URL-encoded text. If you omit the media type entirely, the spec defaults to text/plain;charset=US-ASCII.
This decoder accepts either form: paste a complete data URI or just the Base64 payload. When only the payload is supplied, the format is detected from the first decoded bytes, see below.
How the format is detected
If you paste a raw Base64 string with no data:image/… prefix, the only way to know what kind of image it is is to look at the first few decoded bytes, every common image format starts with a recognisable signature, formally called a "magic number." Browsers do exactly the same check when sniffing MIME types (the procedure is in the WHATWG MIME Sniffing standard). The shortcut is that those signatures translate to predictable Base64 prefixes:
| Format | First bytes (hex) | Base64 prefix |
|---|---|---|
| PNG | 89 50 4E 47 0D 0A 1A 0A | iVBORw0KGgo |
| JPEG | FF D8 FF | /9j/ |
| GIF89a | 47 49 46 38 39 61 | R0lGODlh |
| WebP | 52 49 46 46 … 57 45 42 50 | UklGR |
| BMP | 42 4D ("BM") | Qk |
| SVG (XML text) | starts with <?xml or <svg | PD94bWwg or PHN2Zw |
PNG's signature is one of the cleverer ones in the format zoo. The 89 byte has the high bit set so a 7-bit-only mail relay corrupts it visibly. The next three bytes spell PNG in ASCII so a human running head on the file can recognise it. Then come a DOS line ending (0D 0A), an MS-DOS Ctrl-Z that stops the legacy TYPE command from printing further, and a Unix line feed (0A), between them they detect every common transport that "helpfully" rewrites line endings.
Where Base64 images come from
Most people who land on a tool like this are debugging something. Common situations:
- JSON API responses. JSON has no native binary type, so APIs ship images, signed PDFs, profile pictures and uploaded screenshots as Base64 strings inside JSON fields. Pasting the value here lets you see what it actually was.
- CSS and bundled assets. Webpack and Vite have a small-asset threshold (Vite defaults to 4 KB) that automatically inlines small images as data URIs in the bundled CSS or JS. When debugging "where is this icon coming from?" the data URI lands here.
- HTML email signatures. Gmail, Outlook and Apple Mail inline signature images as data URIs so the image survives forwarding. Designers sometimes need the original logo back.
- CMS and Notion exports. WordPress XML exports, Notion exports and Confluence backups embed thumbnails inline as Base64 to keep the export self-contained.
- QR codes and signature pads. Browser libraries that generate QR codes (qrcode.js) or capture handwritten signatures (signature_pad) typically expose their output as a
data:image/png;base64,…string. - Server-side PDF generation. Tools like Puppeteer, openhtmltopdf and iText accept HTML with inline data URIs. When a logo "doesn't appear" in the rendered PDF, decoding the URI is the fastest way to see whether the bytes were even an image.
Should you inline images as Base64?
The trade-off used to be more interesting. Under HTTP/1.1 every image was a separate blocking request and inlining a tiny icon could shave a real round-trip. Under HTTP/2 and HTTP/3 the case has narrowed sharply. Honest summary:
You gain: zero extra HTTP requests, atomic delivery, and self-contained artefacts that work without external dependencies (single-file demos, email, server-rendered PDFs).
You lose: the browser cannot cache an inlined data URI separately, so the same image on ten pages is re-downloaded with every HTML response. The encoded asset is roughly 33% bigger than the binary equivalent. CDNs cannot deduplicate images embedded across pages. Image-optimisation pipelines (Cloudinary, Vercel, Next.js <Image>) cannot inspect, compress, resize or serve modern formats like AVIF or WebP for inlined assets. The browser also has to decode the Base64 first and the image second, which is extra CPU on every render.
Reasonable rules of thumb: inline images smaller than about 4 KB used in only one place, single-pixel placeholders, and images that need to travel inside a self-contained file. Don't inline anything used on more than one page, anything larger than about 4 KB, anything that should be lazy-loaded, or anything that benefits from format negotiation.
Security: what Base64 doesn't do
Base64 is encoding, not encryption. RFC 4648 §12 explicitly warns it "visually hides" data but provides "no computational confidentiality", anyone can decode it instantly. Don't Base64-encode passwords or API keys thinking it's a security measure.
Two security details worth knowing:
- Top-level navigation to
data:URLs is blocked in modern browsers (opening one in a new tab won't work) to mitigate phishing attacks that rendered fake login pages from data URIs. Subresource use (<img src="data:…">, CSSurl(data:…)) is still allowed. - SVG is special. SVG is XML and SVG documents can contain
<script>elements and event handlers. Loading an SVG into an<img>tag is safe (browsers run a script-disabled renderer), but loading the same SVG into<object>or<iframe>can execute arbitrary JavaScript. This decoder only ever sets<img src>, which is the safe path. If you decoded an SVG from an untrusted source, treat the file like any other untrusted document.
More questions
Why does my Base64 string fail with "InvalidCharacterError"?
Three usual causes: stray whitespace or newlines from a copy-paste (the older MIME Base64 profile wraps lines at 76 characters, which JavaScript's atob() rejects); URL-safe Base64 with - and _ instead of + and /; or stripped trailing = padding so the length isn't a multiple of four. This decoder cleans whitespace, normalises the alphabet and re-pads before decoding, but very corrupted strings still fail.
Do I lose any quality when decoding?
No. Decoding is the exact inverse of encoding, you get back byte-for-byte the original image. The download is in whatever format was in the Base64 (PNG, JPEG, WebP, GIF, BMP, or SVG), with no re-encoding step.
What's the largest data URI a browser will accept?
According to MDN, current limits are around 512 MB for Chromium and Firefox, and around 2 GB for Safari/WebKit. In practice the bottleneck is memory and CPU rather than the URL spec, pastes above roughly 10 MB start to feel sluggish on a typical laptop.
Does anything get sent to a server?
No. Decoding happens entirely in your browser via the native atob() function and a Blob or data URI assigned to an <img> tag. Nothing is uploaded; the page works offline once it's loaded.
Why does every JPEG's Base64 start with /9j/?
Almost every JPEG file in the wild begins with the bytes FF D8 FF (Start-Of-Image marker followed by another marker byte). When you Base64-encode three bytes that are all FF with a D8 in the middle, the bit pattern 11111111 11011000 11111111 splits into 6-bit groups 111111 111101 100011 111111: Base64 alphabet positions 63, 61, 35, 63, which spell /9j/. The fourth character then varies depending on what marker follows (E0 for JFIF, E1 for Exif), but the first three are universal.