छवि से Base64

यह कैसे काम करता है

1. एक image drop करें या pick करें। Browser FileReader API से locally file read करता है। कुछ भी कहीं upload नहीं होता।
2. Encoder bytes convert करता है standard Base64 alphabet का उपयोग करके, हर 3 input bytes A-Z a-z 0-9 + / से drawn 4 ASCII characters बनते हैं, up to दो trailing = padding characters के साथ जब input length 3 का multiple नहीं होती।
3. जो चाहिए उसे copy करें। «Copy Base64» आपको बस encoded string देता है (JSON payloads या backend processing के लिए useful)। «Copy Data URI» आपको पूरा data:image/png;base64,… form देता है जो <img src> attribute में या CSS background-image: url(…) में drop करने के लिए ready है।
4. इसे जहां जाना हो वहां paste करें। Output plain text है, HTML, CSS, JSON, JavaScript, Markdown, या anywhere else में काम करता है जहां string live कर सके।

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

Base64 RFC 4648 (October 2006) में define किया गया है। Encoding एक समय में 24 bits input लेती है (तीन bytes) और उन्हें 64-character alphabet में चार 6-bit indexes के रूप में rewrite करती है। Math exact है: 3 bytes (24 bits) → 4 characters (हर एक 6 bits carry करता है)। जब input length 3 का multiple नहीं होती, encoder output length को 4 का multiple बनाने के लिए = padding characters append करता है।

दो practical consequences:

• Output हमेशा input से ~33% larger होता है। 4/3 ratio algorithm का fundamental है। एक 100 KB image ~133 KB Base64 बनती है। MIME-style 76-character line breaks के साथ overhead लगभग 37% के closer है।
• Output everywhere text-safe है। 64-character alphabet हर common ASCII text channel का intersection है, HTML, JSON, XML, e-mail, URLs (URL-safe variant के साथ), source code। यही पूरा reason है Base64 के exist होने का: binary data को ऐसे systems के through move करना जो text के लिए designed थे।

RFC 4648 §12 एक important non-feature spell out करता है: «Base64 encoding visually hides otherwise easily recognized information, such as passwords, but does not provide any computational confidentiality.» कोई भी किसी भी language में दो lines of code में एक Base64 string decode कर सकता है। यह encoding है, encryption नहीं।

Data URIs: Inline-Image Form

एक «data URI» वह wrapper format है जो एक Base64 string को एक image URL की जगह लेने देता है। RFC 2397 (1998) syntax define करता है:

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

Images के लिए, इसका मतलब है data:image/png;base64,iVBORw0KGgo… एक <img src> attribute में या CSS में background-image: url("data:image/svg+xml;utf8,<svg…>")। ;base64 token browser को बताता है कि data part encoded है; इसके बिना, data percent-encoded text के रूप में लिया जाता है। RFC 2397 itself note करता है कि data URIs «only useful for short values» हैं, एक hint जो एक hard performance rule में age हो गई है।

कब एक Image को Base64 के रूप में Inline करें

• Single-file artefacts। एक e-mail signature में embedded logo जिसे forwarding survive करना हो। CodePen, JSFiddle, या bug-report repro के लिए एक self-contained HTML demo। एक generated PDF जहां image embedded होनी चाहिए ताकि file offline काम करे।
• Tiny critical-path icons। Critical CSS में inline किया गया एक 200-byte chevron या loading spinner एक separate HTTP request trigger करने से faster load हो सकता है, especially slow connections पर।
• Inline JSON / API responses। Avatar uploads, signatures, OCR samples, generated QR codes, कुछ भी जहां API consumer separate URL fetch करने के बजाय bytes inline expect करे।
• Sandboxed iframes या अन्य contexts जो external resource loading prohibit करते हैं।
• Configuration files जहां आप JSON / TOML / YAML के साथ sibling image file नहीं चाहते।

कब एक Image को Base64 के रूप में Inline न करें

अधिकांश production websites के लिए, एक inlined Base64 image एक normal <img> reference से slower है। पांच compounding reasons:

1. 33% size overhead, हमेशा। हर byte encoding के बाद 4/3 bytes cost करता है। एक बार gzip apply होने पर apparent overhead shrink होता है (क्योंकि Base64 repetitive है), लेकिन browser जो bytes parse करता है वे still original से 33% larger हैं।
2. Image को separately cache नहीं किया जा सकता। एक external image.png एक बार fetch होती है और उसे link करने वाले हर page पर reuse होती है। एक Base64 image HTML या CSS के अंदर live करती है और उस file के हर change के साथ re-downloaded होती है।
3. HTML और CSS parsing slow करता है। Render-blocking CSS के अंदर long inlined strings critical path को और आगे push करती हैं। Harry Roberts (CSS Wizardry) ने Base64 images के साथ एक real client stylesheet को 925 KB और बिना 708 KB measured किया, और gzipped 232 KB vs 68 KB। Base64 remove करने से gzipped CSS 70.68% cut हुई।
4. Lazy-load नहीं हो सकती। loading="lazy" attribute एक image fetch defer करता है जब तक user उसके near scroll न करे। Base64 images already document में हैं, defer करने के लिए कुछ नहीं है।
5. HTTP/2 और HTTP/3 ने «too many requests» problem already solve कर दी है। Multiplexing एक single connection को hundreds of files parallel में deliver करने देता है, इसलिए inlining का original justification mostly gone है।

Google के PageSpeed और अधिकांश performance writers का एक practical rule of thumb: केवल तब inline करें जब image ~1-2 KB encoded से कम हो, और केवल तब जब यह critical CSS में above the fold appear हो। इससे बड़ी कोई भी चीज़ almost certainly एक separate file के रूप में better perform करती है।

SVG: Base64 की जगह UTF-8 Encoding Use करें

SVG already text है, इसलिए इसे Base64 के रूप में encode करने से बिना किसी benefit के ~33% bytes waste होती हैं। Smaller form 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' …>");

अधिकांश modern build tools (PostCSS का postcss-inline-svg, Webpack का svg-url-loader) default रूप से URL-encoded form emit करते हैं। Inline SVG के लिए, Base64 के बजाय उस form को prefer करें जब तक specific consumer ;base64 require न करे।

MIME Types जो यह Tool पहचानता है

Data URI का media-type prefix वह है जो consumer को बताता है कि bytes को कैसे interpret करना है। Browser इसे उस file से detect करता है जो आप pick करते हैं:

Privacy और Security Notes

अधिकांश online «image to Base64» sites आपकी file उनके server पर upload करती हैं, वहां encode करती हैं, और result वापस serve करती हैं। इसका मतलब है pre-release UI के screenshots, NDA'd designs, बच्चों की photos, medical scans, या contracts-पर-signatures एक third party के infrastructure से traverse करती हैं। यह tool locally encode करता है, browser का FileReader file को memory में read करता है, encoder आपके device पर JavaScript में run होता है, और page से केवल वही चीज़ निकलती है जो encoded string है जब आप इसे copy करते हैं।

दो Content Security Policy notes जो जानने योग्य हैं यदि आप production में Base64 images ship करते हैं:

• Inlined Base64 images img-src rules bypass करती हैं जब तक आप उन्हें explicitly allow न करें। img-src 'self' जैसा strict CSP data: URIs block करता है। उन्हें allow करने के लिए, img-src 'self' data: लिखें।
• यही CSS-inlined background images पर भी लागू होता है। यदि कोई CSP आपकी inlined backgrounds block कर रही है, तो पहले img-src directive check करें।

सामान्य गलतियाँ

1. Base64 को obfuscation मानना। यह नहीं है। कोई भी इसे किसी भी language में दो lines में decode कर सकता है। Credentials, API keys, या sensitive data को Base64 strings के अंदर «to hide them.» मत डालें।
2. 200 KB hero image inline करना। Image 266 KB encoded हो जाती है, HTML के अंदर stuck हो जाती है, separately cached नहीं हो सकती, lazy-load नहीं हो सकती, और page का first paint visibly slower होता है। इसे normal file के रूप में serve करें।
3. Raw Base64 copy करना जब Data URI चाहिए था। <img src> attribute में एक bare Base64 string broken render होती है, आपको data:image/png;base64, prefix चाहिए। «Copy Data URI» button use करें।
4. SVG को Base64-encode करना। SVG already text है। इसके बजाय URL-encode करें और 33% overhead बचाएं।
5. CSP भूलना। Strict img-src 'self' data URIs block करता है। यदि आप Base64 images ship करते हैं तो data: को directive में add करें।
6. Leading data: prefix वाली Base64 string को decode करने की कोशिश। data:image/...;base64, portion metadata है; इसे Base64 decoder को pass करने से पहले strip करें।
7. Confidential images को server-side encoder में paste करना। यदि URL «encode» कहता है लेकिन network tab एक POST show करता है, तो आपकी image आपकी machine छोड़ चुकी है।

अक्सर पूछे जाने वाले प्रश्न

«Base64» और «Data URI» में क्या अंतर है?

Base64 encoding है (iVBORw0KGgo… जैसी एक string। एक Data URI वह wrapper है जो एक Base64 string को कुछ ऐसी चीज़ में बदलता है जो एक image URL की जगह ले सकती है) data:image/png;base64,iVBORw0KGgo…। Wrapper browser को media type और encoding बताता है ताकि वह जान सके bytes को कैसे interpret करना है। इस tool में दोनों buttons आपको हर form अलग-अलग देते हैं।

क्या Base64 secure है?

नहीं, और यह इसके लिए है नहीं। Base64 encoding है, encryption नहीं। RFC 4648 §12 directly कहता है: यह «does not provide any computational confidentiality.» कोई भी एक Base64 string instantly decode कर सकता है। यदि आपको privacy चाहिए, तो पहले data encrypt करें (AES, आदि के साथ) और फिर transport के लिए ciphertext को Base64 करें।

Image कितनी बड़ी हो सकती है?

Tool द्वारा कोई hard limit नहीं है, क्योंकि encoding आपके browser की memory में होती है। Practical ceiling वह है जो आपका device hold कर सके, typically modern laptops पर tens of MB ठीक हैं। बड़ी constraint consumer support है: कई email clients, browsers, और APIs के अपने data-URI size limits हैं, और कुछ KB से अधिक कुछ भी inline करना performance के लिए rarely sense बनाता है।

मेरी Base64 string file से 33% larger क्यों है?

क्योंकि हर Base64 character 6 bits carry करता है, जबकि हर input byte 8 bits carry करता है। जो smallest unit Base64 remainder के बिना represent कर सकता है वह 3 bytes (24 bits = चार 6-bit characters) है, इसलिए output ratio exactly 4/3 ≈ 1.33 है। इससे बचने वाला कोई Base64 variant नहीं है, यह mathematically encoding में baked in है।

क्या encoded image HTML email में काम करेगी?

Mostly, लेकिन हमेशा नहीं। Apple Mail, modern Gmail, और अधिकांश webmail clients data: images cleanly render करते हैं। Microsoft Outlook desktop historically inconsistent support रहा है, कुछ versions data URIs fine render करते हैं, अन्य उन्हें entirely strip करते हैं। Base64 images को transactional emails में rely करने से पहले अपने target client list में test करें। Broad compatibility के लिए, hosted image URLs still safer bet हैं।

क्या मुझे base64url (- और _ के साथ) use करना चाहिए?

केवल तब यदि आप encoded data एक URL या filename में put कर रहे हैं जहां + और / को otherwise percent-encoding की ज़रूरत होगी। HTML <img src> attributes और CSS background-image values के लिए, standard alphabet काम करता है। RFC 4648 §5 explicitly उन URL/filename cases के लिए URL-safe variant define करता है, और warn करता है कि इसे «should not be referred to as only 'base64'» standard alphabet के साथ confusion से बचने के लिए।

संबंधित टूल