इमेज फ़ॉर्मैट कन्वर्टर

इमेज फ़ॉर्मैट रूपांतरण कैसे काम करता है

जब आप कोई इमेज जोड़ते हैं, तो ब्राउज़र उसे createImageBitmap() से रॉ पिक्सल में डिकोड करता है। टूल उन पिक्सल को पूरे रिज़ॉल्यूशन पर एक HTML कैनवास पर बनाता है, फिर आपके चुने MIME टाइप — image/png, image/jpeg या image/webp — के साथ canvas.toBlob() कॉल करके उन्हें नए फ़ॉर्मैट में दोबारा एन्कोड करता है। एन्कोडिंग ब्राउज़र के अपने इमेज कोडेक करते हैं, इसलिए आउटपुट मानक-अनुरूप होता है और फ़ाइल कभी आपके टैब से बाहर नहीं जाती।

• PNG में — लॉसलेस: बिल्कुल वही पिक्सल सुरक्षित रहते हैं, पारदर्शिता सहित।
• JPG में — लॉसी: पिक्सल आपकी क्वालिटी सेटिंग पर दोबारा कंप्रेस होते हैं, और कोई भी पारदर्शिता आपके चुने बैकग्राउंड रंग (डिफ़ॉल्ट सफ़ेद) पर सपाट कर दी जाती है।
• WebP में — क्वालिटी < 100 पर लॉसी, पारदर्शिता बनाए रखते हुए। समान क्वालिटी पर आमतौर पर तीनों में सबसे छोटी फ़ाइल।

PNG बनाम JPG बनाम WebP — आपको कौन-सा चुनना चाहिए?

मोटा नियम: अपनी वेबसाइट के लिए WebP (सबसे छोटी), पारदर्शिता या तीखे टेक्स्ट के लिए PNG, और फ़ोटो के लिए तथा जहाँ कोई फ़ॉर्म माँगे वहाँ JPG।

आम रूपांतरण

• PNG से JPG — किसी बड़े स्क्रीनशॉट को छोटा करें या ऐसे अपलोड फ़ॉर्म के लिए एक्सपोर्ट करें जो केवल JPEG स्वीकारता है। याद रखें, बैकग्राउंड रंग किसी भी पारदर्शिता की जगह ले लेता है।
• WebP से PNG — डाउनलोड की गई WebP को पुराने सॉफ़्टवेयर या ऐसे एडिटर के लिए सर्वत्र-समर्थित PNG में बदलें जो WebP नहीं खोल सकते।
• WebP से JPG — किसी आधुनिक वेब इमेज को ईमेल, मैसेजिंग या पुराने CMS के लिए JPEG में बदलें।
• JPG से WebP — पेज-वेट घटाने और अपनी साइट पर Core Web Vitals सुधारने के लिए फ़ोटो को WebP में दोबारा एन्कोड करें।
• JPG से PNG — JPEG आर्टिफ़ैक्ट बढ़ाए बिना एडिट करने के लिए एक लॉसलेस कॉपी पाएँ (यह उस डिटेल को वापस नहीं लाएगा जो JPG पहले ही खो चुकी है)।

सर्वोत्तम परिणामों के लिए सुझाव

• नया फ़ॉर्मैट नहीं, छोटी फ़ाइल चाहिए? किसी सटीक KB सीमा तक पहुँचने के लिए इमेज कंप्रेसर या साइज़ तक कंप्रेस करें इस्तेमाल करें।
• अलग डाइमेंशन चाहिए? यहाँ बदलें, फिर रीसाइज़ करें — या यदि आप पिक्सल साइज़ भी बदल रहे हैं तो पहले रीसाइज़ करें।
• iPhone HEIC फ़ोटो? समर्पित HEIC से JPG कन्वर्टर इस्तेमाल करें — HEIC को एक विशेष डिकोडर चाहिए जो यह टूल बंडल नहीं करता।
• JPG/WebP फ़ोटो के लिए क्वालिटी 80–90 देखने में 100 जैसी ही होती है पर कहीं छोटी। किसी कड़े साइज़ बजट तक पहुँचने पर ही इससे नीचे जाएँ।
• पारदर्शिता बनाए रखनी है? PNG या WebP में बदलें, कभी JPG में नहीं।

फ़ॉर्मैट का एक संक्षिप्त परिचय

आप जिन फ़ॉर्मैट के बीच बदलते हैं, उनमें से हर एक किसी विशेष समस्या को हल करने के लिए बना था, और पृष्ठभूमि जानने से किसी एक को चुनना आसान हो जाता है।

• GIF (1987) — CompuServe द्वारा बनाया गया, नेतृत्व Steve Wilhite ने किया। इसने वेब एनिमेशन और सरल ऑन/ऑफ़ (1-बिट) पारदर्शिता पेश की, पर इसकी पैलेट 256 रंगों तक सीमित है। यह LZW कंप्रेशन इस्तेमाल करता है, और LZW पर पेटेंट (Unisys के पास) ही वह कारण है जिसकी वजह से PNG बनाई गई। वे पेटेंट 2004 तक समाप्त हो गए; आज GIF वास्तव में केवल छोटे विरासती एनिमेशन के लिए इस्तेमाल करने योग्य है।
• JPEG (1992) — Joint Photographic Experts Group का ISO/IEC 10918 मानक। इसके लॉसी, फ़ोटो-केंद्रित कंप्रेशन ने डिजिटल फ़ोटोग्राफ़ी को व्यावहारिक बनाया और यह तीन दशकों से भी अधिक समय से सर्वत्र समर्थित रहा है, यही वजह है कि अपलोड फ़ॉर्म अब भी इसे माँगते हैं।
• PNG (1996) — एक W3C अनुशंसा जिसे एक स्वयंसेवी समूह ने ख़ासतौर पर GIF के रॉयल्टी-मुक्त विकल्प के रूप में बनाया, जब Unisys ने LZW पेटेंट लागू करना शुरू किया। यह लॉसलेस है, पूर्ण अल्फा चैनल और ट्रूकलर समर्थन करती है, पर इसमें मूल एनिमेशन नहीं है।
• WebP (2010) — Google का फ़ॉर्मैट, जो VP8 वीडियो कोडेक से लिया गया। यह लॉसी और लॉसलेस दोनों करता है, दोनों मोड में पारदर्शिता समर्थन करता है, और एनिमेशन भी जोड़ता है — एक सच्चा ऑलराउंडर।
• AVIF (2019) — समूह में सबसे नया, जो Alliance for Open Media के रॉयल्टी-मुक्त AV1 वीडियो कोडेक पर बना है। यह आमतौर पर ऊपर सभी से बेहतर कंप्रेस करता है और HDR, वाइड कलर तथा 12-बिट तक गहराई जोड़ता है।

आप BMP (Microsoft का पुराना बिना-कंप्रेस्ड बिटमैप, बड़ा पर लॉसलेस) और TIFF (एक लचीला कंटेनर जिसे Aldus ने 1986 में बनाया, अब भी प्रिंट और स्कैनिंग में अभिलेखीय पसंदीदा) से भी मिलेंगे।

लॉसी कंप्रेशन असल में क्या करता है

JPEG, WebP और AVIF लॉसी हैं: वे वह डिटेल हटा देते हैं जिसे आपकी आँख शायद ही नोटिस करे, बदले में नाटकीय रूप से छोटी फ़ाइलें देते हैं। JPEG सबसे स्पष्ट उदाहरण है। यह इमेज को 8×8 पिक्सल ब्लॉक में बाँटता है, हर एक को एक डिस्क्रीट कोसाइन ट्रांसफ़ॉर्म (DCT) से गुज़ारकर आवृत्तियों के रूप में व्यक्त करता है, फिर उन आवृत्तियों को क्वांटाइज़ करता है — बारीक आवृत्तियों को हटाते हुए। "क्वालिटी" स्लाइडर असल में यही नियंत्रित करता है कि वह क्वांटाइज़ेशन कितनी आक्रामकता से हो। यह क्रोमा सबसैंपलिंग (आमतौर पर 4:2:0) भी इस्तेमाल करता है: चूँकि हम चमक को रंग की तुलना में कहीं अधिक तीक्ष्णता से देखते हैं, JPEG पूरी चमक-डिटेल रखता है पर रंग-रिज़ॉल्यूशन आधा कर देता है।

उस डिज़ाइन के दिखने वाले परिणाम हैं। कम क्वालिटी पर आपको ब्लॉकिंग (8×8 ग्रिड स्पष्ट होने लगता है) और रिंगिंग या "मॉस्किटो नॉइज़" दिखती है — तीखे किनारों और टेक्स्ट के आसपास टिमटिमाते धब्बे। यही कारण है कि JPEG स्क्रीनशॉट, लोगो और लाइन आर्ट के लिए ख़राब है, जहाँ किनारे ही सब कुछ हैं। दो और तथ्य जानने योग्य:

• जनरेशन लॉस असली है। हर बार जब आप कोई JPEG खोलते और दोबारा सेव करते हैं, यह डिकोड और दोबारा क्वांटाइज़ होती है, इसलिए आर्टिफ़ैक्ट बढ़ते हैं। किसी फ़ोटो को कई JPEG सेव में एडिट करना उसे दृश्य रूप से बिगाड़ देता है; किसी लॉसलेस फ़ॉर्मैट में काम करें और अंत में एक बार JPEG में एक्सपोर्ट करें।
• JPEG को PNG में बदलना खोई डिटेल वापस नहीं ला सकता। किसी JPEG की PNG कॉपी उस बिंदु से आगे लॉसलेस होती है, पर वह उन आर्टिफ़ैक्ट को बनाए रखती है जो JPEG पहले ही पका चुकी थी — यह बस उन्हें और बिगड़ने से रोकती है।
• प्रोग्रेसिव JPEG इमेज को मोटे-से-बारीक स्कैन के रूप में संग्रहीत करती है, इसलिए एक धुँधला पूर्वावलोकन जल्दी दिखता है और तीखा होता जाता है — बेसलाइन के समान फ़ाइल-साइज़ पर धीमे कनेक्शन पर सुविधाजनक।

रंग गहराई और अल्फा चैनल

ऊपर तुलना तालिका में "पारदर्शिता" एक कॉलम है, पर अंतर्निहित अंतर और गहरे हैं। PNG किसी इमेज को इंडेक्स्ड पैलेट (256 रंगों तक, GIF की तरह), 24-बिट ट्रूकलर (लाल, हरे और नीले के लिए 8-8 बिट — लगभग 16.7 मिलियन रंग), या 32-बिट RGBA के रूप में संग्रहीत कर सकती है, जो सहज, परिवर्तनशील पारदर्शिता के लिए एक 8-बिट अल्फा चैनल जोड़ता है। वही परिवर्तनशील अल्फा है जिसकी वजह से किसी PNG लोगो का किनारा मुलायम, एंटी-एलियस्ड हो सकता है जो किसी भी बैकग्राउंड पर घुल जाता है।

इसके विपरीत, JPEG हमेशा प्रति चैनल 8 बिट होता है और उसमें कोई अल्फा चैनल बिल्कुल नहीं होता — यह पारदर्शिता संग्रहीत ही नहीं कर सकता। वही एक सीमा कारण है कि जब आप JPG में बदलते हैं तो इस कन्वर्टर को पारदर्शी पिक्सल किसी बैकग्राउंड रंग पर सपाट करने पड़ते हैं। WebP और AVIF पूरी समस्या से बच जाते हैं: दोनों अपने लॉसी मोड में भी एक अल्फा चैनल रखते हैं, इसलिए वे आपको पारदर्शिता और छोटी फ़ाइलें दोनों देते हैं।

AVIF, WebP और आधुनिक वेब

अपनी वेबसाइट के लिए, नए फ़ॉर्मैट स्पष्ट जीत हैं। Google बताता है कि WebP फ़ाइलें समान क्वालिटी पर आमतौर पर JPEG से लगभग 25–34% छोटी होती हैं, और web.dev नोट करता है कि कुछ मामलों में AVIF JPEG से 50% से भी अधिक छोटी हो सकती है, कम ब्लॉकिंग आर्टिफ़ैक्ट और कठोर किनारों के आसपास कम रंग-रिसाव के साथ। छोटी इमेज तेज़ी से लोड होती हैं, और चूँकि कोई इमेज अक्सर पेज का Largest Contentful Paint तत्व होती है, आधुनिक फ़ॉर्मैट चुनना सीधे उस Core Web Vital को बेहतर बनाता है।

ब्राउज़र समर्थन अब वह बाधा नहीं है जो कभी था। WebP हर मौजूदा ब्राउज़र में काम करता है (Safari ने इसे 2020 में जोड़ा)। AVIF Chrome, Firefox, Safari और — हाल ही में — Edge में समर्थित है, जो अधिकांश उपयोगकर्ताओं को कवर करता है। तो फिर सब कुछ AVIF में क्यों न बदलें? कुछ ईमानदार कारण: कुछ पुराने सॉफ़्टवेयर, इमेज एडिटर, कंटेंट मैनेजमेंट सिस्टम, ईमेल क्लाइंट और अपलोड फ़ॉर्म अब भी WebP या AVIF स्वीकार नहीं करते, और AVIF एन्कोडिंग धीमी और अधिक CPU-भूखी है। सुरक्षित तरीक़ा है आधुनिक फ़ॉर्मैट को एक फ़ॉलबैक के साथ परोसना, न कि हर जगह एक ही थोपना:

उन्हें देने का स्वच्छ तरीक़ा HTML <picture> तत्व है। अपने आधुनिक स्रोतों को एक type एट्रिब्यूट के साथ सूचीबद्ध करें और ब्राउज़र को पहला ऐसा चुनने दें जिसे वह समझे, एक सर्वव्यापी <img> तक गिरते हुए:

• <source type="image/avif"> — AVIF समर्थन करने वाले ब्राउज़र इस्तेमाल करते हैं
• <source type="image/webp"> — अगला फ़ॉलबैक
• <img src="photo.jpg"> — बाकी सबके लिए गारंटीड डिफ़ॉल्ट

यह आधुनिक विज़िटर को सबसे छोटी फ़ाइल देता है जबकि बाकी सभी अब भी इमेज देखते हैं — और यहाँ आप जो रूपांतरण करते हैं वही उन वैकल्पिक स्रोतों को बनाने का तरीक़ा है।

क्यों एक "बदली गई" फ़ाइल बड़ी निकल सकती है

रूपांतरण कंटेनर और कंप्रेशन योजना बदलता है, इमेज की अंतर्निहित जटिलता नहीं — इसलिए फ़ाइल-साइज़ किसी भी दिशा में जा सकता है, और लोग अक्सर हैरान होते हैं जब यह बढ़ता है। सामान्य कारण:

• फ़ोटो से PNG। PNG लॉसलेस है, इसलिए उसे किसी फ़ोटो के हर हल्के से अलग पिक्सल को ईमानदारी से दर्ज करना पड़ता है। एक 200 KB की JPEG फ़ोटो PNG के रूप में कई मेगाबाइट तक फूल सकती है। PNG सपाट ग्राफ़िक्स और टेक्स्ट पर चमकती है, निरंतर-टोन फ़ोटो पर नहीं।
• क्वालिटी बहुत ऊँची सेट। क्वालिटी 100 पर कोई JPG या WebP वह डिटेल रखता है जो आप नहीं देख सकते और फ़ाइल को फुला देता है। फ़ोटो के लिए, क्वालिटी 80–90 देखने में समान है और कहीं छोटी।
• पहले से ऑप्टिमाइज़ स्रोत। यदि मूल पहले से अच्छी तरह कंप्रेस्ड था, किसी और लॉसी फ़ॉर्मैट में दोबारा एन्कोड करना मदद नहीं कर सकता और थोड़ा ओवरहेड भी जोड़ सकता है।

समाधान है फ़ॉर्मैट को सामग्री से मिलाना: फ़ोटो को किसी लॉसी फ़ॉर्मैट (JPG, WebP या AVIF) में रखें, PNG को ग्राफ़िक्स और पारदर्शिता के लिए सुरक्षित रखें, और जब आपका असली लक्ष्य किसी अलग फ़ॉर्मैट के बजाय छोटी फ़ाइल हो तो समर्पित इमेज कंप्रेसर का सहारा लें।

एनिमेशन: GIF, APNG, WebP और AVIF

इनमें से केवल कुछ ही फ़ॉर्मैट चल सकते हैं, जो मायने रखता है यदि आपका स्रोत एनिमेटेड है। GIF मूल एनिमेटेड वेब फ़ॉर्मैट था, पर यह प्रति फ़्रेम 256 रंगों तक सीमित है और बड़ी फ़ाइलें बनाता है। PNG के मूल स्पेक में कोई एनिमेशन नहीं है — उसके लिए अलग APNG एक्सटेंशन चाहिए। WebP और AVIF दोनों GIF के साइज़ के एक अंश पर पूर्ण-रंग एनिमेशन समर्थन करते हैं, यही वजह है कि छोटे लूपिंग क्लिप तेज़ी से एनिमेटेड WebP के रूप में परोसे जा रहे हैं। इस और किसी भी कैनवास-आधारित कन्वर्टर के लिए एक व्यावहारिक चेतावनी: कैनवास के ज़रिए दोबारा बनाना एक ही फ़्रेम कैप्चर करता है, इसलिए किसी एनिमेटेड GIF को स्थिर फ़ॉर्मैट में बदलने पर केवल एक फ़्रेम रहता है। गति बनाए रखने के लिए, इसे शुरू से अंत तक एनिमेशन-सक्षम फ़ॉर्मैट में रखें।

EXIF, GPS और प्राइवेसी पहलू

फ़ोन या कैमरे से सीधे आई फ़ोटो में EXIF मेटाडेटा का एक छिपा ब्लॉक होता है: कैमरा और लेंस मॉडल, ठीक तारीख़ और समय, इस्तेमाल की गई सेटिंग — और अक्सर उस स्थान के GPS निर्देशांक जहाँ तस्वीर ली गई थी। जब आप कोई फ़ोटो सार्वजनिक रूप से पोस्ट करते हैं तो वह स्थान डेटा एक सच्चा प्राइवेसी जोखिम है, क्योंकि यह आपका घर या किसी बच्चे का स्कूल उजागर कर सकता है। इस टूल के काम करने के तरीक़े, यानी ब्राउज़र के कैनवास के ज़रिए दोबारा एन्कोड करने, का एक उपयोगी दुष्प्रभाव यह है कि आउटपुट एक साफ़ इमेज होती है जिसमें कोई EXIF ब्लॉक नहीं — कैमरा विवरण और GPS स्थान अपने आप हट जाते हैं। ऑनलाइन साझा करते समय यह एक प्राइवेसी जीत है। दूसरी ओर: यदि आपको वह मेटाडेटा वास्तव में चाहिए (कैटलॉगिंग या कॉपीराइट के लिए), तो अपनी मूल फ़ाइल रखें, क्योंकि बदली गई कॉपी में वह नहीं होगा।

बिना अंदाज़ा लगाए क्वालिटी सेटिंग चुनना

क्वालिटी स्लाइडर केवल लॉसी फ़ॉर्मैट — JPG और WebP — पर लागू होता है; PNG इसे पूरी तरह नज़रअंदाज़ करती है क्योंकि यह हमेशा लॉसलेस है। उन लॉसी फ़ॉर्मैट के लिए, कुछ मोटे नियम अनुमान लगाने की ज़रूरत ख़त्म कर देते हैं:

• फ़ोटो के लिए 80–90 सबसे अच्छा बिंदु है। परिणाम क्वालिटी 100 से देखने में अभिन्न होता है, पर फ़ाइल नाटकीय रूप से छोटी। स्लाइडर के आख़िरी दस अंक ऐसी डिटेल के लिए बहुत सारे बाइट जोड़ते हैं जिसे लगभग कोई नहीं देख सकता।
• लगभग 70 से नीचे, आर्टिफ़ैक्ट दिखते हैं। आप किनारों के आसपास ब्लॉकिंग और टिमटिमाती "मॉस्किटो नॉइज़" देखने लगते हैं — और वे टेक्स्ट, लोगो और तीखी रेखाओं पर सबसे ख़राब दिखते हैं, इसलिए इतना नीचे तभी जाएँ जब आपको कोई सख़्त साइज़ बजट पूरा करना हो।
• WebP और AVIF कम क्वालिटी पर JPEG की तुलना में अधिक शालीनता से घटते हैं, इसलिए यदि आपको आक्रामक रूप से छोटी फ़ाइल चाहिए तो वे डिटेल बेहतर बनाए रखते हैं।
• ग्राफ़िक्स, स्क्रीनशॉट और तीखे टेक्स्ट वाली किसी भी चीज़ के लिए, उच्च-क्वालिटी JPEG बिल्कुल इस्तेमाल न करें — PNG या लॉसलेस WebP चुनें। कोई भी JPEG क्वालिटी सेटिंग कठोर किनारों को किसी लॉसलेस फ़ॉर्मैट जितनी साफ़ नहीं संभालती।

संक्षेप में: लॉसी क्वालिटी फ़ोटो के लिए एक डायल है, जहाँ थोड़ा अगोचर नुक़सान कहीं छोटी फ़ाइल दिलाता है। हर किनारा-भारी चीज़ के लिए, फ़ॉर्मैट का चुनाव स्लाइडर से ज़्यादा मायने रखता है।

संबंधित टूल

• इमेज कंप्रेसर (फ़ाइल साइज़ घटाएँ)
• साइज़ (KB) तक कंप्रेस करें
• इमेज रीसाइज़र (डाइमेंशन बदलें)
• HEIC से JPG (iPhone फ़ोटो)
• इमेज से Base64 (डेटा URI)
• इमेज क्रॉप करें (अनुपात, वृत्त)