What Base64 formats are supported?

You can paste a raw Base64 string or a complete data URI like data:image/png;base64,... Supported image types include PNG, JPEG, WebP, GIF, BMP, and SVG.

Is there a size limit?

There is no hard limit, but very large Base64 strings over 5-10 MB may be slow to process depending on your device.

How do I encode an image to Base64?

Use the Image to Base64 Converter tool, just drag and drop an image to get its Base64 string.

Which image formats can I decode?

Whatever the original Base64 encodes, such as PNG, JPG, WebP, GIF, SVG, or BMP. The format is detected from the data URI prefix (e.g. `data:image/png;base64,…`) or by inspecting the first few bytes of the decoded data.

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 whatever format was in the Base64 string; there is no re-encoding step.

Base64 छवि डिकोडर

छवि का पूर्वावलोकन और डाउनलोड करने के लिए Base64 स्ट्रिंग पेस्ट करें।

आपका डेटा आपके डिवाइस से बाहर नहीं जाता

Base64 स्ट्रिंग या डेटा URI

डिकोड की गई छवि यहाँ दिखाई देगी

कैसे उपयोग करें

पेस्ट करें इनपुट क्षेत्र में 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 स्ट्रिंग मिल जाए।

Base64 वास्तव में क्या है

Base64 एक binary-to-text encoding scheme है जो RFC 4648 (October 2006) में define है। यह 64-character alphabet use करती है, A-Z, a-z, 0-9, plus + और /: arbitrary bytes को printable ASCII के रूप में represent करने के लिए। Binary input के हर तीन bytes exactly output के चार characters बनते हैं, क्योंकि 6 bits (एक Base64 character) और 8 bits (एक byte) का lowest common multiple 24 है। यह four-to-three ratio ही कारण है कि Base64-encoded file original binary से roughly 33% larger होती है।

जब input length तीन का multiple नहीं होती, Base64 = से pad करती है ताकि output हमेशा चार characters का multiple हो: एक trailing byte दो characters plus == produce करता है; दो trailing bytes तीन characters plus = produce करते हैं। कुछ encoders padding strip करते हैं, इसलिए एक robust decoder को string atob() पर pass करने से पहले re-pad करना होता है।

RFC 4648 एक URL-safe variant भी define करता है (कभी-कभी base64url कहा जाता है) जो + को - से और / को _ से swap करता है। JWTs इसे use करते हैं। यह decoder दोनों alphabets normalise करता है ताकि आपको यह सोचना न पड़े कि आपको कौन सा मिला है।

Data URI scheme

RFC 2397 (August 1998) data: URL scheme define करता है। Full grammar है:

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

एक typical inline PNG कुछ ऐसा दिखता है data:image/png;base64,iVBORw0KGgo…। ;base64 token एक marker है (note करें = sign की absence) जो browser को बताता है payload को percent-encoded text के रूप में treat करने की बजाय Base64 से decode करें। यदि आप ;base64 omit करते हैं, data URL-encoded text के रूप में interpret होता है। यदि आप media type entirely omit करते हैं, spec text/plain;charset=US-ASCII default करता है।

यह decoder दोनों forms accept करता है: complete data URI paste करें या केवल Base64 payload। जब केवल payload दी जाती है, format पहले decoded bytes से detect होती है, नीचे देखें।

Format कैसे Detect होती है

यदि आप data:image/… prefix के बिना raw Base64 string paste करते हैं, यह जानने का एकमात्र तरीका कि यह किस प्रकार की image है, पहले कुछ decoded bytes देखना है, हर common image format एक recognisable signature से शुरू होती है, जिसे formally «magic number» कहा जाता है। Browsers MIME types sniff करते समय exactly यही check करते हैं (procedure WHATWG MIME Sniffing standard में है)। Shortcut यह है कि वे signatures predictable Base64 prefixes में translate होते हैं:

Format	प्रथम bytes (hex)	Base64 उपसर्ग
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 पाठ)	`<?xml` या `<svg` से शुरू होता है	`PD94bWwg` या `PHN2Zw`

PNG का signature format zoo में cleverer ones में से एक है। 89 byte का high bit set है इसलिए 7-bit-only mail relay इसे visibly corrupt करता है। अगले तीन bytes ASCII में PNG spell करते हैं इसलिए file पर head run करने वाला इंसान इसे पहचान सकता है। फिर एक DOS line ending (0D 0A) आता है, एक MS-DOS Ctrl-Z जो legacy TYPE command को आगे print करने से रोकता है, और एक Unix line feed (0A), ये सब मिलकर हर common transport detect करते हैं जो «helpfully» line endings rewrite करता है।

Base64 images कहां से आती हैं

इस जैसे tool पर land करने वाले अधिकांश लोग कुछ debug कर रहे होते हैं। Common situations:

JSON API responses। JSON में कोई native binary type नहीं है, इसलिए APIs images, signed PDFs, profile pictures और uploaded screenshots को JSON fields के अंदर Base64 strings के रूप में ship करती हैं। यहां value paste करने से आप देख सकते हैं कि वह actually क्या थी।
CSS और bundled assets। Webpack और Vite का एक small-asset threshold है (Vite default 4 KB है) जो bundled CSS या JS में small images को automatically data URIs के रूप में inline करता है। «where is this icon coming from?» debug करते समय data URI यहां आती है।
HTML email signatures। Gmail, Outlook और Apple Mail signature images को data URIs के रूप में inline करते हैं ताकि image forwarding में survive करे। Designers को कभी-कभी original logo वापस चाहिए होता है।
CMS और Notion exports। WordPress XML exports, Notion exports और Confluence backups thumbnails को Base64 के रूप में inline embed करते हैं ताकि export self-contained रहे।
QR codes और signature pads। Browser libraries जो QR codes (qrcode.js) generate करती हैं या handwritten signatures (signature_pad) capture करती हैं typically अपना output data:image/png;base64,… string के रूप में expose करती हैं।
Server-side PDF generation। Puppeteer, openhtmltopdf और iText जैसे tools HTML को inline data URIs के साथ accept करते हैं। जब rendered PDF में logo «appear नहीं होता», URI decode करना fastest way है यह देखने के लिए कि bytes actually एक image थीं या नहीं।

क्या आपको Images को Base64 के रूप में Inline करना चाहिए?

Trade-off पहले अधिक interesting था। HTTP/1.1 के under हर image एक separate blocking request थी और tiny icon को inline करना real round-trip बचा सकता था। HTTP/2 और HTTP/3 के under case significantly narrow हो गया है। Honest summary:

आप gain करते हैं: zero extra HTTP requests, atomic delivery, और self-contained artefacts जो external dependencies के बिना काम करते हैं (single-file demos, email, server-rendered PDFs)।

आप lose करते हैं: browser separately inlined data URI cache नहीं कर सकता, इसलिए दस pages पर same image हर HTML response के साथ re-downloaded होती है। Encoded asset binary equivalent से roughly 33% बड़ी होती है। CDNs pages में embedded images deduplicate नहीं कर सकते। Image-optimisation pipelines (Cloudinary, Vercel, Next.js <Image>) inlined assets को inspect, compress, resize या AVIF या WebP जैसे modern formats में serve नहीं कर सकते। Browser को भी पहले Base64 decode करना होता है और फिर image, जो हर render पर extra CPU है।

Reasonable rules of thumb: roughly 4 KB से छोटी images जो केवल एक जगह use होती हों, single-pixel placeholders, और images जिन्हें self-contained file के अंदर travel करना हो, उन्हें inline करें। एक से अधिक page पर use होने वाली कोई भी चीज़, roughly 4 KB से बड़ी कोई भी चीज़, lazy-load होनी चाहिए कुछ भी, या format negotiation से benefit करने वाली कोई भी चीज़ inline न करें।

Security: Base64 क्या नहीं करता

Base64 encoding है, encryption नहीं। RFC 4648 §12 explicitly warn करता है कि यह data को «visually hides» करता है लेकिन «no computational confidentiality» provide करता है, कोई भी इसे instantly decode कर सकता है। Passwords या API keys को Base64-encode करके यह न सोचें कि यह security measure है।

जानने योग्य दो security details:

Modern browsers में data: URLs पर top-level navigation blocked है (एक नए tab में एक open करना काम नहीं करेगा) उन phishing attacks को mitigate करने के लिए जो data URIs से fake login pages render करती थीं। Subresource use (<img src="data:…">, CSS url(data:…)) अभी भी allowed है।
SVG special है। SVG XML है और SVG documents में <script> elements और event handlers हो सकते हैं। SVG को <img> tag में load करना safe है (browsers script-disabled renderer run करते हैं), लेकिन same SVG को <object> या <iframe> में load करना arbitrary JavaScript execute कर सकता है। यह decoder केवल <img src> set करता है, जो safe path है। यदि आपने untrusted source से SVG decode किया है, file को किसी भी अन्य untrusted document की तरह treat करें।