क्रॉप

इमेज क्रॉप करें गोल क्रॉप करें

ऑप्टिमाइज़

इमेज कंप्रेस करें इमेज अपस्केल करें बैकग्राउंड हटाएं

बदलाव

इमेज रीसाइज़ करें

कन्वर्ट

अन्य

JPG को PDF में बदलें

PNG से WebP, छोटी फ़ाइलें जो ट्रांसपेरेंसी रखती हैं

भारी PNG को एक हल्के WebP से बदलें जो अपनी ट्रांसपेरेंसी रखता है और तेज़ी से लोड होता है।

या यहां इमेज ड्रॉप करें

त्वरित उत्तर

Araluma एक PNG को WebP में बदलता है और पारदर्शी हिस्से सहेजता है। एक तस्वीर दें तो ब्राउज़र का इमेज इंजन उसे आपके अपने डिवाइस पर फिर से बनाता है, इसलिए वह कहीं नहीं भेजी जाती। कई एक साथ दें तो वे हमारे सर्वर तक जाती हैं, जो उन सबको साथ में देखता है और एक डाउनलोड लौटाता है, फिर उस डाउनलोड को लगभग 2 घंटे में साफ़ कर देता है। जहाँ PNG पारदर्शी था, WebP भी पारदर्शी रहता है, क्योंकि WebP पूरा अल्फ़ा चैनल रखता है, और इसी वजह से जब आप कट-आउट को चपटा किए बिना हल्की फ़ाइल चाहते हैं तो यह JPG को हरा देता है। Google के अपने WebP आँकड़ों के अनुसार, बिना हानि वाला WebP बराबर PNG से लगभग 26 प्रतिशत नीचे रहता है, और अल्फ़ा वाला हानियुक्त WebP आकार के लगभग एक तिहाई के पास पहुँचता है। यहाँ जो निकलता है वह लगभग बिना हानि वाली सेटिंग पर हानियुक्त WebP है, जो बिट-स्तर के थोड़े विवरण को छोटी फ़ाइल के बदले देता है, जबकि सामान्य स्क्रीन आकारों पर स्रोत PNG जैसा ही दिखता है। पिक्सेल-सटीक संग्रह प्रतियों के लिए मूल PNG रखें।

PNG को WebP में कैसे बदलें

PNG को WebP में कैसे बदलें

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

ट्रांसपेरेंट पिक्सेल WebP में आर-पार जाते हैं

ट्रांसपेरेंट पिक्सेल WebP में आर-पार जाते हैं

पहले नतीजा: आपके PNG में जहाँ-जहाँ आर-पार था, WebP बनने पर भी वहाँ-वहाँ आर-पार ही रहता है, और इसकी जड़ है उसके भीतर बैठा 8-बिट alpha channel। इसी वजह से बाद में कुछ सफ़ेद नहीं होता, किसी कट-आउट के गिर्द कोई किनारा नहीं चमकता, और किसी एडिटर में सफ़ाई की नौबत नहीं आती। JPG के बरअक्स रखकर देखें तो बात और साफ़ होती है, क्योंकि JPG के पास alpha है ही नहीं और उसे साफ़ पिक्सेल किसी ठोस रंग से ढकने पड़ते हैं, जबकि WebP उन्हें जस का तस उठा लेता है। लोगो, आइकन, प्रोडक्ट कट-आउट, इंटरफ़ेस मॉकअप, गोल कोनों वाले स्क्रीनशॉट, आर-पार बैकड्रॉप पर टिकी हर चीज़, सब पूरे-के-पूरे पार होते हैं। इसके लिए कोई स्विच पलटने को नहीं, यह अपने आप होता है, क्योंकि alpha ढोना उसी काम का हिस्सा है जिसके लिए WebP गढ़ा गया।

PNG से WebP पर जाने की वजहें

PNG से WebP पर जाने की वजहें

पहले ब्राउज़र की बात निपटा लें: Chrome, Firefox, Safari और Edge कब के WebP को नेटिव पहचानते हैं, इसलिए दिखेगा या नहीं, यह सवाल ही नहीं उठता। असल खिंचाव साइज़ का है। Google के आधिकारिक आँकड़ों में lossless वाला रूप बराबर PNG से करीब 26 प्रतिशत हल्का बैठता है, और alpha वाला lossy रूप तुलनीय PNG के एक-तिहाई के आस-पास। फ़ाइल जैसे ही हल्की होती है, पहली स्क्रीन की सबसे बड़ी तस्वीर जल्दी आ जाती है, और Largest Contentful Paint की चिंता ठीक यही है, जो Google के Core Web Vitals में से एक है और जिससे वह क्रम तय करता है। तभी तो PageSpeed Insights अपने next-gen-formats सुझाव में PNG का नाम तक ले लेता है, और आपके WebP पर आते ही वह झंडा बुझ जाता है।

क्वालिटी सेटिंग और lossy का सौदा

क्वालिटी सेटिंग और lossy का सौदा

पहले खरी बात: यह WebP तकनीकी वर्गीकरण में सचमुच lossy है, एक हूबहू lossless कॉपी के मुक़ाबले यह ज़रा-सी बिट-स्तर की सटीकता दे आता है। पर Araluma जिस लगभग-लॉसलेस बिंदु पर इसे थामता है वह फ़ोटो और ग्राफ़िक्स दोनों का ख़याल रखता है, और आम देखने के साइज़ पर यह उसी PNG जैसा दिखता है। रोज़मर्रा के लोगो, आइकन, इंटरफ़ेस एसेट और फ़ोटो पर वह फ़र्क़ सतह तक उभरता ही नहीं। फ़ायदे में बदलें तो: फ़ोटो आम तौर पर 50 से 70 प्रतिशत तक दुबली होती हैं, और यह उस संरचनात्मक बढ़त के ऊपर है जो WebP पहले से PNG पर रखता है। बस मेडिकल स्कैन या आर्काइवल मास्टर जैसे पिक्सेल तक सटीक काम में ही PNG को बुनियाद बनाएँ और WebP को एक्सपोर्ट बनने दें।

PNG वास्तव में कहाँ बदला जाता है

PNG वास्तव में कहाँ बदला जाता है

यह इस पर बँटता है कि आप कितनी देते हैं। एक PNG बदलें तो पूरा काम टैब में, ब्राउज़र के अपने इमेज इंजन पर, आपके डिवाइस पर होता है, कुछ भी ऊपर नहीं जाता और फ़ाइल के बारे में कुछ भी नोट नहीं होता। खुद जाँचें, DevTools खोलें, उस एक तस्वीर को बदलते समय नेटवर्क पैनल खुला रखें, और उसे ले जाने वाले शून्य आउटगोइंग अनुरोध गिनें। एक मुट्ठी साथ बदलें तो वे हमारे सर्वर पर चढ़ती हैं, जो उन सबको देखता है और एक डाउनलोड लौटाता है। वह डाउनलोड लगभग 2 घंटे में हमारे सर्वर से साफ़ हो जाता है, और जैसे ही आप सहेजते हैं आप उसे मिटा सकते हैं। इस तरह एक तस्वीर कभी ब्राउज़र नहीं छोड़ती, और एक बैच हमारे सर्वर पर केवल उतनी देर रहता है जितनी आप जो ले जाते हैं उसे जोड़ने में लगती है।

जब ओरिजिनल PNG ही सही चुनाव है

जब ओरिजिनल PNG ही सही चुनाव है

अब दूसरी ओर भी देखें, WebP दूर तक जाता तो है पर हर दरवाज़े से नहीं। प्रिंट पाइपलाइन ज़्यादातर इसे किनारे रखती हैं, गिनी-चुनी डिज़ाइन प्रोग्राम और भीतरी कंटेंट सिस्टम आज भी सिर्फ़ PNG मानती हैं, और कुछ ऑपरेटिंग सिस्टम PNG को बेझिझक ड्रैग-एंड-ड्रॉप करते हैं पर WebP के लिए प्लगइन माँगते हैं। एक सूरत और संभालने लायक़ है: वे वर्किंग फ़ाइलें जिन्हें डेस्कटॉप ऐप में बार-बार खोला और बदला जाएगा, क्योंकि बार-बार डिकोड और दोबारा बनाना बोझ जमा देता है, ऐसे में lossless PNG को मास्टर रखना समझदारी है। तो साफ़ बँटवारा यही है, PNG स्रोत बने और WebP वेब के लिए एक्सपोर्ट। कभी उलटा चलना हो, WebP से वापस PNG, तो webp-to-png टूल वह राह संभाल लेता है।

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

  1. एक PNG थमाएँ

    PNG को पेज पर खिसकाएँ, या पिकर में उसे ढूँढें। पारदर्शी हिस्से साथ आते हैं। एक बदलें तो वह आपकी मशीन पर रहती है, कई छोड़ें तो वे साथ निपटाने के लिए हमारे सर्वर पर चढ़ती हैं।

  2. पीछे टिक जाएँ

    आपको और कुछ नहीं करना। एक आम तस्वीर लगभग उतनी ही जल्दी WebP बन जाती है जितनी जल्दी आपकी उँगली उठती है, बीच में न कोई Convert चरण न कोई स्पिनर।

  3. उसे सिकुड़ते देखें

    नतीजा बताता है कि वह कितना बड़ा निकला। साफ़ जगहें साफ़ रहती हैं, और WebP को उस PNG से दिखने में हल्का होना चाहिए जिससे आपने शुरुआत की।

  4. अपना WebP रखें

    Download पर एक टैप उसे लिख देता है, पुराना नाम, ताज़ा .webp अंत। और भी कतार में हैं? हर एक को पेज पर डालें और वे एक-एक करके निकलते हैं।

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

PNG को WebP में बदलते समय क्या ट्रांसपेरेंसी बनी रहेगी?

रहेगी। चूँकि WebP एक पूरा alpha channel थामता है, आपके PNG का हर साफ़ हिस्सा WebP बनने पर भी साफ़ रहता है। यही एक तथ्य वजह है कि जब भी आप एक ट्रांसपेरेंट PNG से शुरू करें तो लक्ष्य के रूप में WebP, JPG को मात देता है, क्योंकि JPG के पास कोई alpha नहीं और उसे साफ़ धब्बों को किसी ठोस रंग से रंगना पड़ता है जबकि WebP कट-आउट को ठीक वैसा छोड़ता है जैसा उसने पाया। लोगो, आइकन, प्रोडक्ट शॉट, आर-पार बैकड्रॉप पर टिके इंटरफ़ेस टुकड़े, सब के सब पूरे पार होते हैं, आपसे कुछ अतिरिक्त माँगे बिना।

PNG को WebP में क्यों बदलें?

तस्वीर जितनी दुबली, उतनी जल्दी पहुँची, और Largest Contentful Paint नापता ठीक यही है कि पहली स्क्रीन की बड़ी तस्वीर कितनी फुर्ती से आई, और Google उसे रैंकिंग में दर्ज रखता है। इसीलिए WebP पर आना फ़ायदे का सौदा है, Google के आँकड़ों से lossless रूप बराबर PNG से करीब 26 प्रतिशत हल्का, alpha वाला lossy रूप किसी एक के एक-तिहाई तक दुबला, और ट्रांसपेरेंसी तथा शक्ल दोनों जस की तस। PageSpeed Insights भी अपने इमेज ऑडिट में PNG को next-gen-format के मौक़े की तरह इंगित करता है। रही दिखने की बात, तो Chrome, Firefox से लेकर Safari, Edge तक हर बड़ा ब्राउज़र बिना किसी सहारे WebP पढ़ लेता है।

क्या PNG को WebP में बदलने से क्वालिटी घटती है?

Araluma जिस लगभग-लॉसलेस सेटिंग का इस्तेमाल करता है, उस पर फ़ोटो और ग्राफ़िक्स आम देखने के साइज़ पर स्रोत PNG जैसे ही दिखते हैं। यहाँ थमा WebP तकनीकी रूप से lossy है, इसलिए बिट-स्तर की एक झलक सटीकता एक छोटी फ़ाइल की ओर जाती है। रोज़मर्रा के वेब काम के लिए, लोगो, आइकन, फ़ोटो, वह फ़र्क़ अदृश्य है। पिक्सेल-सटीक या आर्काइवल काम के लिए PNG रखें और WebP को डिलीवरी कॉपी मानें। बदलाव आपके PNG को अछूता छोड़ देता है, आपके डिवाइस पर वैसा ही बैठा हुआ जैसा वह था।

WebP, PNG से कितना छोटा होता है?

Google के आधिकारिक WebP आँकड़े lossless WebP को बराबर PNG से करीब 26 प्रतिशत नीचे रखते हैं, और alpha वाले lossy WebP को तुलनीय की लगभग एक-तिहाई साइज़ पर। ठीक अनुपात सामग्री पर सवार रहता है, जहाँ चौड़ी साफ़ जगहों और ठोस रंग ब्लॉक वाले ग्राफ़िक्स सबसे ज़्यादा पाते हैं, जबकि व्यस्त, बारीक फ़ोटो एक छोटी पर फिर भी उपयोगी गिरावट देखते हैं। किसी भी हाल में WebP हल्का निकलता है और ट्रांसपेरेंसी बच जाती है।

क्या यहाँ PNG को WebP में बदलना सुरक्षित है?

यह इस पर निर्भर करता है कि आप एक तस्वीर बदलते हैं या कई। एक PNG सीधे ब्राउज़र में फिर से बनती है, इसलिए वह फ़ाइल नहीं भेजी जाती, और आप DevTools खोलकर और बदलने के बीच में नेटवर्क पैनल देखकर जाँच सकते हैं, जहाँ कोई आउटगोइंग छवि अनुरोध नहीं दिखता। कई एक साथ बदलें तो वे साथ निपटाने के लिए हमारे सर्वर पर चढ़ती हैं, फिर वह डाउनलोड लगभग 2 घंटे में साफ़ हो जाता है, और सहेजते ही आप उसे खुद हटा सकते हैं। किसी भी तरह, आपके डाउनलोड को जोड़ने के अलावा आपकी तस्वीर का कुछ नहीं रहता।

क्या WebP सभी ब्राउज़र में चलता है?

चलता है, हर व्यावहारिक मक़सद के लिए। नेटिव पढ़ना हर जगह तब पहुँचा जब 2020 में Safari 14 आया, और Chrome, Edge तथा Firefox से जा मिला, जो साथ मिलकर लगभग हर उस ब्राउज़र को बनाते हैं जो लोग सचमुच चलाते हैं। अपवाद सचमुच पुराने वाले और कुछ एम्बेडेड वेबव्यू हैं, और ऐसे ऑडियंस के लिए जिसमें वे हो सकते हैं, PNG सतर्क चुनाव रहता है। पिछले पाँच साल के किसी ब्राउज़र पर कोई भी बिना झंझट WebP पाता है। किसी ख़ास मामले की पुष्टि चाहें तो caniuse.com पर WebP की एंट्री सपोर्ट को साफ़ बिछा देती है।

विवरण

अच्छे गोल क्रॉप के पीछे शिल्प, प्रारूपों और छोटे निर्णयों पर टीम के नोट्स।

WebP, PNG से छोटे साइज़ कैसे हासिल करता है
असल जड़ दो कंप्रेशन तौर-तरीक़ों में है, और PNG का DEFLATE उनमें से बस एक के बराबर है। पहला तौर-तरीक़ा एक तिनका भी नहीं छोड़ता, स्थानिक और रंग प्रेडिक्शन को एक ऐसे एंट्रॉपी चरण से जोड़ता है जो DEFLATE से कहीं सधा हुआ है, और Google के अनुसार आम तस्वीरों पर करीब 26 प्रतिशत ज़्यादा बचत देता है। दूसरा तौर-तरीक़ा छोड़ना जानता है, वीडियो वाली दुनिया से एक ब्लॉक-आधारित ट्रांसफ़ॉर्म उधार लेता है और ठीक वही डिटेल गिराता है जिसे आँख मुश्किल से पकड़ती है। पूरा करिश्मा ट्रांसपेरेंसी की परत पर है, alpha आते ही WebP उसे एक अलग पटरी पर एक तिनका छोड़े बिना सहेजता है और RGB को ही lossy बरतता है, इसी से मेल खाती विज़ुअल क्वालिटी पर ट्रांसपेरेंट lossy WebP PNG के एक-तिहाई तक उतर आता है। DEFLATE एक भी अक्षर छोड़े बिना डटा रहता है, सो वह अवधारणात्मक रियायत उसके हाथ कभी नहीं आती, साइज़ की यह खाई वहीं से जन्म लेती है।
alpha channel विस्तार से
पैमाना खोलकर देखें: किसी पिक्सेल की ओपेसिटी, 0 की पूरी सफ़ाई से लेकर 255 की पूरी ठोसपन तक, PNG और WebP दोनों उसे 8 बिट में दर्ज करते हैं। दोबारा बनाते वक़्त प्लेटफ़ॉर्म इमेज इंजन हर पिक्सेल की RGBA पढ़ता है और सिर्फ़ alpha वाली पटरी को सीधे WebP के कंप्रेशन में डालता है, RGB चाहे जैसे बरता जाए, alpha हमेशा lossless कंप्रेशन के नीचे टिका रहता है। तो 0 का पूरा पारदर्शी, 1 से 254 के बीच का अधूरा पारदर्शी, और 255 का ठोस, हर एक WebP में रत्ती भर फ़र्क़ बिना अपनी जगह पाता है। किसी नरम छाया वाले या साफ़ बैकग्राउंड पर अक्षरों के मुलायम किनारों वाले लोगो पर वह नज़ाकत पूरी सवार होकर निकलती है। JPG यह कर ही नहीं सकता, उसके कंटेनर में alpha की कोई ख़ाना है ही नहीं, और एनकोड से पहले उसे तस्वीर किसी बैकग्राउंड रंग पर दबानी पड़ती है।
Core Web Vitals और इमेज फ़ॉर्मेट का चुनाव
पहले इस आदतन क़ुसूरवार को पहचान लें: महज़ वज़न से PNG अक्सर Largest Contentful Paint को घसीट गिराता है, एक 4K फ़ोटोग्राफ़िक PNG कई मेगाबाइट का होता है जबकि वही तस्वीर एक लगभग-लॉसलेस WebP में अक्सर बस एक चुटकी रह जाती है। और LCP नापता यह है कि पेज का सबसे बड़ा दिखने वाला तत्व व्यूपोर्ट में आने में कितनी देर लेता है, ज़्यादातर कंटेंट पेज पर वह hero तस्वीर होती है, और Google उसे Core Web Vitals के रैंकिंग संकेत में जोड़ लेता है। PageSpeed Insights तो next-gen-formats वाली कड़ी में सीधे PNG का नाम लेता है। सो किसी पेज के क्रिटिकल रेंडर पाथ पर अड़ी PNG को WebP में बदलना, मापी गई रफ़्तार के लिहाज़ से सबसे फ़ायदेमंद अकेली चालों में से है। समयरेखा भी निश्चिंत करती है, Chrome 2011, Firefox 2019, Safari 2020, और Edge अपने Chromium वाले फेर के बाद से।
Lossy आउटपुट और लगभग-लॉसलेस सेटिंग
WebP 0 से 100 तक एक क्वालिटी घुंडी खोलता है, जहाँ ऊँची संख्याएँ ज़्यादा डिटेल थामती हैं और ज़्यादा बाइट लेती हैं। Araluma उस घुंडी को एक लगभग-लॉसलेस बिंदु पर जमा देता है, जो फ़ोटो, इंटरफ़ेस ग्राफ़िक्स और आइकन की आम वेब श्रेणियों भर में वफ़ादारी को साइज़ के विरुद्ध तौलने को चुना गया है। इस बिंदु पर आउटपुट आम स्क्रीन दूरियों पर स्रोत PNG से अप्रभेद्य पढ़ा जाता है। सख़्ती से, एक सच्चे lossless एनकोड के विरुद्ध थोड़ी बिट-स्तर की सटीकता फिसलती है, इसलिए डिकोड किए गए WebP और ओरिजिनल PNG के बीच बाइट-दर-बाइट जाँच नन्हे संख्यात्मक अंतर उभारेगी, सब के सब फ़ोटोग्राफ़िक सामग्री पर मानव दृष्टि की दहलीज़ के नीचे बैठे। मेडिकल स्कैन, सैटेलाइट इमेजरी या आर्काइवल संरक्षण के लिए, जहाँ lossless एक कठोर नियम है, सही चाल यह है कि PNG रखें और WebP को महज़ एक डिलीवरी एक्सपोर्ट बरतें, वर्किंग कॉपी नहीं।
मेटाडेटा का व्यवहार
एक PNG को WebP में बदलना EXIF, IPTC और XMP फ़ील्ड को आउटपुट से बुहार देता है, जो तीनों बड़े ब्राउज़र इंजनों में से हर एक करता है। रंग प्रोफ़ाइल वहीं हैं जहाँ इंजन रास्ते बाँट लेते हैं। Chrome और Safari sRGB टैग को WebP पर सवार रखते हैं, जबकि Firefox सब साफ़ कर देता है, ICC प्रोफ़ाइल समेत। तो WebP हर जगह sRGB-सुरक्षित पढ़ा जाता है, फिर भी स्रोत PNG पर बैठा एक वाइड-गैमट टैग, Display-P3, Adobe RGB, ProPhoto RGB, Firefox से होकर नहीं टिकेगा। वह फ़ासला रंग-गंभीर पेशेवर काम में काटता है, इसलिए जब सच्ची रंग वफ़ादारी को साथ सवारी करनी ही हो, ऐसा कन्वर्टर चुनें जो जान-बूझकर ICC डेटा लिखता हो, या बाद में प्रोफ़ाइल टैग को इस काम के लिए बने मेटाडेटा एडिटर से वापस दबा दें।
कब PNG रखें और कब WebP काफ़ी है
फ़ैसला लैंडिंग देखकर हो जाता है। मंज़िल कोई वेब पेज या वेब ऐप है और दर्शक 2020 के बाद का ब्राउज़र है, तो WebP वही सही एक्सपोर्ट है। उसे Figma, Sketch या Affinity Designer में खुलना हो, तो पहले अपने ठीक उसी संस्करण में सपोर्ट टटोल लें, हर संस्करण का मिज़ाज अलग है। प्रिंट की ओर है, तो PNG या TIFF पर टेक लें, अधिकतर प्रिंट RIP WebP को हवा समझते हैं। ईमेल से जा रही है, तो PNG ज़्यादा भरोसे का, ईमेल क्लाइंट आधुनिक फ़ॉर्मेट देखकर अक्सर मुँह फेर लेते हैं। और वह बार-बार बदली और दोबारा सेव की जाने वाली वर्किंग फ़ाइल हो, तो PNG मास्टर रहे। कुल मिलाकर, लगभग-लॉसलेस WebP डिलीवरी में बढ़िया है, आर्काइव और एडिट इस छोर पर PNG ही ज़्यादा सुहाता है, सीधा बँटवारा यही, PNG मूल थामे, WebP वेब पर जाए।