आँकड़ों और विज्ञापन के लिए कुकीज़
हम आँकड़ों और विज्ञापन के लिए कुकीज़ इस्तेमाल करते हैं, दोनों Google को जाती हैं। मना करने से आपको दिखने वाली किसी चीज़ में कोई फ़र्क़ नहीं पड़ता।निजता पेज पढ़ें
JPGसेWebP
एक बार में 100 फ़ाइलें। फ़ॉर्मेट अलग-अलग हों तो भी चलेगा।
ये एक के बाद एक बदलती हैं और साथ में एक ZIP बनकर उतरती हैं।
यहाँ आप JPG को WebP में बदलते हैं, मुफ़्त और बिना खाते के: फ़ाइल ऊपर छोड़िए और कुछ ही सेकंड में नतीजा डाउनलोड के लिए तैयार मिलेगा। कन्वर्ज़न आपके अपने ब्राउज़र के भीतर होता है, इसलिए फ़ाइल कभी अपलोड नहीं होती। यह Windows, macOS और Linux पर वैसे ही चलता है जैसे iPhone और Android पर, और कनेक्शन काट देने पर भी चलता रहता है।
कहाँ चलता है
आपके ब्राउज़र में। फ़ाइल कभी अपलोड नहीं होती।
कुछ नुक़सान के साथ
आकार के बदले कुछ बारीक़ी जाती है। JPG जो सँभाल सकता है, वह सब WebP नहीं सँभाल सकता।
फ़ाइल आकार की सीमा
हर फ़ाइल 100 MB तक, मुफ़्त, बिना खाते के।






इकलौती अच्छी वजह कोई वेबसाइट है। दिखने में उसी गुणवत्ता पर WebP, JPG से क़रीब एक चौथाई से एक तिहाई छोटा रहता है, और तस्वीरों के मामले में यही उस पेज और इस पेज का फ़र्क़ है जो तुरंत खड़ा हो जाए और जिसमें स्क्रॉल करते हुए इंतज़ार करना पड़े।
जो तस्वीर आप किसी को भेज रहे हैं या किसी फ़ॉर्म में चढ़ा रहे हैं, उसके लिए यह फ़ायदे का नहीं। वहाँ सिर्फ़ यह मायने रखता है कि सामने वाला उसे खोल सके, और JPG को वह हमेशा खोल लेता है, WebP को क़रीब-क़रीब हमेशा।
आम फ़ोटो पर, दिखने में उसी गुणवत्ता पर, क़रीब पच्चीस से पैंतीस प्रतिशत। बड़े ठहरे हिस्सों वाली तस्वीरों में — आसमान, दीवार, स्टूडियो की पृष्ठभूमि — इससे ज़्यादा, और पत्तों या बजरी वाली बेहद बारीक़ तस्वीरों में कम।
जिसकी उम्मीद नहीं रखनी चाहिए वह है आधा हो जाना। अगर कोई औज़ार ऐसा वादा करता है, तो उसने आम तौर पर साथ ही गुणवत्ता का स्तर भी गिरा दिया है — तब बचत फ़ॉर्मेट से नहीं, छोड़ देने से आती है।
JPG पहले से ही नुक़सान के साथ कंप्रेस्ड है। उससे WebP बनाने पर दूसरा एनकोडर उसी को एनकोड करता है जो पहले वाले ने छोड़ा था — वह असली तस्वीर कभी देखता ही नहीं और कुछ लौटा नहीं सकता।
ऊँची गुणवत्ता पर इसका कुछ दिखता नहीं। पर जो नहीं होता वह यह है: ज़ोर से कंप्रेस की गई JPG को बदलकर दोबारा अच्छा बना देना। जहाँ पहले से ख़ामियाँ हैं, वे साथ चली आती हैं और कभी-कभी बड़े जतन से एनकोड भी हो जाती हैं।
WebP में वही संख्या वह नहीं कहती जो JPEG में कहती है। 80 पर WebP क़रीब वैसा दिखता है जैसा 90 पर JPG, और वह छोटा भी रहता है — जो अपनी अभ्यस्त संख्या वैसी की वैसी उठा लेता है, वह या तो जगह गँवाता है या गुणवत्ता।
वेबसाइट की फ़ोटो के लिए 80 के आसपास का मान भरोसेमंद चुनाव है। उससे नीचे त्वचा के रंगों और मुलायम ढालों पर दिखने लगता है, और उससे ऊपर फ़ाइल फ़ायदे से तेज़ बढ़ती है।
WebP बिना नुक़सान भी कर सकता है, और चित्रों तथा स्क्रीन रिकॉर्डिंग के लिए वही सही चुनाव है — वहाँ वह PNG को भी पीछे छोड़ देता है। पर उस फ़ोटो के लिए नहीं जो किसी JPG से आई हो।
वजह सीधी है: बिना नुक़सान हर पिक्सेल को ठीक वैसा ही सँभालता है जैसा वह है — JPG के कंप्रेशन के निशानों समेत। तब नतीजा शुरुआत वाली फ़ाइल से बड़ा निकलता है और फिर भी उसकी सारी ख़ामियाँ ढोता है।
ब्राउज़र में व्यावहारिक रूप से हर जगह, और बरसों से। बाहर बात दूसरी है: कुछ इमेज एडिटर, पुराने व्यूअर, अटैचमेंट सँभालने वाले कुछ प्रोग्राम, और कहीं-कहीं ऐसे अपलोड बॉक्स जो अड़कर सिर्फ़ JPG और PNG लेते हैं।
इसलिए नियम छोटा है। अपनी वेबसाइट के लिए: WebP। हर उस चीज़ के लिए जो ऐसे लोगों तक जा रही है जिनके प्रोग्राम आप नहीं जानते: JPG। आकार का फ़ायदा एक लौटाई हुई फ़ाइल के लायक़ नहीं।
WebP EXIF सँभाल सकता है, पर सँभालेगा या नहीं यह औज़ार पर निर्भर है — और बहुत सारे प्रोग्राम WebP में लिखी वह जानकारी पढ़ते ही नहीं, भले वह अंदर हो। इसलिए न यह मानकर चलिए कि वह साथ जाएगी, न यह कि वह ग़ायब हो जाएगी।
जो तस्वीर इंटरनेट पर जानी है, उसके लिए दूसरी बात ही असली है: छुट्टी की फ़ोटो नियम से उस मकान के निर्देशांक ढोती है जहाँ आप ठहरे थे। अगर उन्हें जाना है, तो वह काम साफ़-साफ़ किया जाना चाहिए, उम्मीद पर नहीं छोड़ा जाना चाहिए।
WebP किसी एक मक़सद के लिए बनाई गई प्रति है, उसकी जगह लेने वाली नहीं। उससे वापस अच्छा JPG गिन निकालना होता नहीं — वह उस तस्वीर पर तीसरा दौर होता जो दो पहले ही झेल चुकी है।
जब तक शुरुआत वाली तस्वीर कहीं पड़ी है, आगे की हर माँग मिनटों का सवाल है। अगर वह ऊपर से लिख दी गई, तो अब उपलब्ध सबसे अच्छी प्रति वही है जो कभी बनी सबसे छोटी थी।
बदलना ब्राउज़र में होता है, आपकी अपनी मशीन पर। कुछ अपलोड नहीं होता, कुछ बीच में रखा नहीं जाता, और हम आपकी तस्वीरें कभी देखते नहीं — ऐसा कोई सर्वर है ही नहीं जहाँ वे पहुँचें।
यही वजह है कि आप यहाँ पचास फ़ाइलें एक साथ बदल सकते हैं, बिना इसके कि कोई खाता माँगे या दैनिक सीमा खींचे। इसमें हमारा कोई बैंडविड्थ ख़र्च नहीं होता, क्योंकि हमारी लाइन से कुछ गुज़रता ही नहीं।
| JPG | WebP | |
|---|---|---|
| पूरा नाम | JPEG तस्वीर | WebP तस्वीर |
| फ़ाइल एक्सटेंशन | .jpg, .jpeg, .jpe | .webp |
| मीडिया टाइप | image/jpeg | image/webp |
| कंप्रेशन | नुक़सान के साथ — छोटा आकार गुणवत्ता देकर ख़रीदा जाता है | सेटिंग के हिसाब से दोनों में से कोई भी |
WebP में कैप्शन, क्रेडिट और कीवर्ड वाले IPTC फ़ील्ड और GPS निर्देशांक के लिए जगह नहीं है, इसलिए वह JPG फ़ाइल से आगे नहीं जाता। असली फ़ाइल फेंकने से पहले यह देख लेना काम आता है — और अगर फेंकना ही मक़सद था, तो यह जान लेना काम आता है।
WebP पारदर्शिता सँभाल सकता है और JPG नहीं। यह वह जगह है जो नतीजे के पास है और जिसे असली फ़ाइल ने कभी इस्तेमाल ही नहीं किया: बदलने से पारदर्शी पृष्ठभूमि बनती नहीं, बाद में बनाना बस मुमकिन हो जाता है।
WebP एनिमेशन ढो सकता है; JPG फ़ाइल एक ही फ़्रेम है। बाहर ऐसी फ़ाइल आती है जिसमें एक तस्वीर है, और वह ऐसे फ़ॉर्मेट में है जो इससे ज़्यादा सँभाल सकता था।
Adobe Photoshop और GIMP JPG और WebP — दोनों पढ़ लेते है, इसलिए आप नतीजे को असली फ़ाइल के बग़ल में रखकर देख सकते हैं, बिना दूसरा प्रोग्राम खोले।
नतीजा असली से बड़ा होगा और बेहतर नहीं। JPG पहले ही बारीक़ी फेंक चुका है और WebP बचे हुए को बिना और फेंके सँभालता है: यह आगे का नुक़सान रोकता है, पहले वाला लौटाता नहीं।
JPG Joint Photographic Experts Group का फ़ॉर्मेट है, जो 1992 में आया। यह हर चैनल पर 8 बिट में दर्ज करता है।
WebP Google का है और 2010 से चला आ रहा है, और RFC 9649 में तय किया गया है। Adobe Photoshop, GIMP और Squoosh इस फ़ॉर्मेट को पढ़ लेते है।
JPG 1992 में आया और WebP 2010 में। किसी को सौंपने के लिए आम तौर पर पुराना वाला ज़्यादा सुरक्षित रहता है; नया वाला वही काम कम बाइट में कर देता है।
नहीं। यह कन्वर्ज़न पूरी तरह आपके ब्राउज़र में होता है, इसलिए फ़ाइल आपके डिवाइस से बाहर नहीं जाती। आप ख़ुद जाँच सकते हैं: डेवलपर टूल्स का नेटवर्क टैब खोलिए और कुछ बदल कर देखिए। आपको पेज ख़ुद दिखेगा और आँकड़ों तथा विज्ञापन के वे अनुरोध दिखेंगे जिनसे इस सेवा का ख़र्च निकलता है — और एक भी ऐसा अनुरोध नहीं जो आपकी फ़ाइल साथ ले जा रहा हो। इस जोड़ी के पीछे jSquash है, तस्वीरों के संदर्भ कोडेक के WebAssembly संस्करण; आपका ब्राउज़र इसे एक बार उतारता है और फिर सहेज कर रखता है।
हाँ। न खाता, न वॉटरमार्क, और आप कितनी फ़ाइलें बदलते हैं इसकी कोई छत नहीं: यह आपकी अपनी मशीन पर चलता है, इसलिए हमारा कुछ ख़र्च ही नहीं होता। ब्राउज़र 100 MB तक की फ़ाइलें सँभाल लेता है। jSquash आपकी अपनी मशीन पर उतरता है और वहीं चलता है — इसीलिए उस पर कोई गिनती नहीं है।
WebP कंप्रेस करता है, इसलिए कुछ डेटा जाता है। तयशुदा सेटिंग पर यह पकड़ में नहीं आता; पक्का करना हो तो गुणवत्ता बढ़ा दीजिए।
नतीजा असली से बड़ा होगा और बेहतर नहीं। JPG पहले ही बारीक़ी फेंक चुका है और WebP बचे हुए को बिना और फेंके सँभालता है: यह आगे का नुक़सान रोकता है, पहले वाला लौटाता नहीं।
WebP में कैप्शन, क्रेडिट और कीवर्ड वाले IPTC फ़ील्ड और GPS निर्देशांक के लिए जगह नहीं है, इसलिए वह JPG फ़ाइल से आगे नहीं जाता। असली फ़ाइल फेंकने से पहले यह देख लेना काम आता है — और अगर फेंकना ही मक़सद था, तो यह जान लेना काम आता है।
WebP पारदर्शिता सँभाल सकता है और JPG नहीं। यह वह जगह है जो नतीजे के पास है और जिसे असली फ़ाइल ने कभी इस्तेमाल ही नहीं किया: बदलने से पारदर्शी पृष्ठभूमि बनती नहीं, बाद में बनाना बस मुमकिन हो जाता है।
यह पेज एक को दूसरे में बदलता है। अगर आप बदल नहीं रहे बल्कि चुन रहे हैं, तो JPG vs WebP बताता है कि किसे कब लेना है और कौन किस काम में कमज़ोर है।
इस पेज पर JPG और WebP के बारे में जो कहा गया है, वह जाँचा जा सकता है, और ये रहे वे दस्तावेज़ जो उसे तय करते हैं।