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



JPEG XL में एक क्षमता है जो इस परिवार में किसी और के पास नहीं — यह किसी मौजूदा JPEG को pixels में डिकोड किए बिना उसके coefficients दोबारा लपेट सकता है, और लगभग बीस प्रतिशत छोटी फ़ाइल बनाता है जिससे मूल JPEG bit-for-bit वापस बन सकती है।
यह converter यह नहीं करता। इस साइट पर हर image रूपांतरण अपने स्रोत को raw pixels में डिकोड करता है और नतीजे को फिर से एनकोड करता है। जो मिलता है वह आपकी तस्वीर का एक नया lossy encode है — छोटा, थोड़ा अलग, और आपकी शुरुआती फ़ाइल में वापस नहीं बदला जा सकता।
JPEG mozjpeg से एक 8-bit RGB buffer में डिकोड होती है, और libjxl उस buffer को आपकी चुनी quality पर एनकोड करता है, डिफ़ॉल्ट 82। इस साइट की अपनी sample तस्वीर पर, 8,924 बाइट्स की JPG 7,240 बाइट्स की JXL बनती है — लगभग उन्नीस प्रतिशत छोटी।
फ़र्क़ संख्या से ज़्यादा मायने रखता है। दोबारा-एनकोड से आया उन्नीस प्रतिशत एक generation की गुणवत्ता खर्च करता है और उलटा नहीं जा सकता; recompression से आया उन्नीस प्रतिशत कुछ नहीं खर्चता।
libjxl दो command-line प्रोग्राम भेजता है, cjxl और djxl, और दोनों मुफ़्त, open-source हैं। cjxl को JPEG दी जाए तो यह डिफ़ॉल्ट रूप से lossless transcode करता है, और djxl इसे उलटकर मूल JPEG वापस देता है।
यह यहाँ उपलब्ध क्यों नहीं है इसकी वजह वैचारिक नहीं, architectural है। यह pipeline pixels में डिकोड करके फिर एनकोड करने के इर्द-गिर्द बनी है, और coefficient-level JPEG transcode एक ख़ास मामला है जो इसे पूरी तरह बायपास करता है।
JPEG पहले ही जानकारी फेंक चुकी है, और जो बचता है उसमें उसकी अपनी artefacts भी हैं — flat जगहों में block boundaries, हार्ड edges पर ringing। ये अब बस तस्वीर हैं, और JXL encoder उन्हें सटीक रूप से दोहराने पर bits खर्च करता है।
यह कितना बुरा लगता है यह पूरी तरह मूल पर निर्भर है। किसी कैमरे से आई high-quality JPEG 82 पर दोबारा-एनकोड बहुत कम बदलाव दिखाती है। किसी messaging app से गुज़री JPEG में पहले से artefacts हैं।
Control 1 से 100 तक चलता है, 82 से शुरू होकर। चूँकि स्रोत पहले से lossy है, इसे थोड़ा ऊँचा सेट करने की दलील बनती है — encoder ऐसी तस्वीर दोबारा बनाने की कोशिश कर रहा है जिसमें ऐसी structure है जो उसने ख़ुद नहीं डाली।
रेंज का ऊपरी हिस्सा अलग व्यवहार करता है — quality 100 पर 256x256 gradient पर 262,144 में से सिर्फ़ 334 samples एक level से इधर-उधर थीं। quality 100 पर JXL JPG से कहीं ज़्यादा बड़ी होती है।
JPEG EXIF, XMP, IPTC, ICC profile और अक्सर GPS निर्देशांक रखती है, और किसी photograph collection के लिए ये pixels जितनी ही क़ीमती होती हैं। इनमें से कुछ नहीं बचता, क्योंकि रूपांतरण raw pixels में डिकोड करता है और दोबारा एनकोड करता है।
किसी एक तस्वीर के लिए यह अक्सर स्वागत योग्य है। किसी library migration के लिए यह असली समस्या है, और यह दूसरी वजह है कि cjxl उस काम के लिए सही टूल है।
इस साइट की अपनी sample तस्वीर पर डिफ़ॉल्ट quality पर, वही तस्वीर JPG के रूप में 8,924 बाइट्स, WebP के रूप में 14,700, AVIF के रूप में 17,599, और JXL के रूप में 7,240 है। JPEG XL इन चारों में सबसे छोटी है।
Support ठीक उलटे क्रम में चलता है। JPG हर जगह खुलती है, WebP हर मौजूदा ब्राउज़र में, AVIF आधुनिक ब्राउज़रों में, JXL कुछ में। भेजी या प्रकाशित होने वाली तस्वीर के लिए यह क्रम हावी रहता है।
हाँ की दलील असली है — डिस्क का लगभग पाँचवाँ हिस्सा वापस, या lossless transcode से और भी ज़्यादा। ना की दलील यह है कि JPEG हर वह image फ़ॉर्मेट है जो सबसे ज़्यादा readable है, और जो library आपके इस्तेमाल किए tools में खुलना बंद कर दे वह storage की बचत से कहीं ज़्यादा क़ीमती है।
बचाव लायक़ बीच का रास्ता है JPEG रखना और JXL को प्रयोग मानना, या cjxl इस्तेमाल करना ताकि migration उलटी जा सके।
mozjpeg डिकोड करता है और libjxl एनकोड करता है, दोनों WebAssembly में compile होकर आपके ब्राउज़र में ही चलते हैं। तस्वीर के बारे में कुछ भी नेटवर्क पार नहीं करता।
मुफ़्त सीमा 100 MB प्रति फ़ाइल है। Batch काम करते हैं — फ़ोल्डर छोड़िए, हर फ़ाइल अपनी progress के साथ बदलती है, नतीजे ZIP बनकर लौटते हैं।
| JPG | JXL | |
|---|---|---|
| पूरा नाम | JPEG तस्वीर | JPEG XL |
| फ़ाइल एक्सटेंशन | .jpg, .jpeg, .jpe | .jxl |
| मीडिया टाइप | image/jpeg | image/jxl |
| कंप्रेशन | नुक़सान के साथ — छोटा आकार गुणवत्ता देकर ख़रीदा जाता है | सेटिंग के हिसाब से दोनों में से कोई भी |
| पहली बार प्रकाशित | 1992 | 2021 |
| प्रकाशक | Joint Photographic Experts Group | Joint Photographic Experts Group |
| विनिर्देश | ITU-T T.81 | ISO/IEC 18181 |
| लाइसेंस | खुला मानक | खुला मानक |
| आज की स्थिति | मौजूदा | सीमित उपयोग |
| बिट डेप्थ | 8 | 32 |
| रंग जो यह दर्ज कर सकता है | RGB, ग्रेस्केल, YCbCr | RGB, ग्रेस्केल, वाइड गैमट |
| सबसे बड़ी इमेज | हर तरफ़ 65,535 px | — |
| ब्राउज़र में खुलता है | हर ब्राउज़र | कुछ ब्राउज़र |
| इसकी जगह विचारणीय | WebP, AVIF, HEIC | AVIF, WebP, PNG |
JXL में कैप्शन, क्रेडिट और कीवर्ड वाले IPTC फ़ील्ड और GPS निर्देशांक के लिए जगह नहीं है, इसलिए वह JPG फ़ाइल से आगे नहीं जाता। असली फ़ाइल फेंकने से पहले यह देख लेना काम आता है — और अगर फेंकना ही मक़सद था, तो यह जान लेना काम आता है।
JXL पारदर्शिता सँभाल सकता है और JPG नहीं। यह वह जगह है जो नतीजे के पास है और जिसे असली फ़ाइल ने कभी इस्तेमाल ही नहीं किया: बदलने से पारदर्शी पृष्ठभूमि बनती नहीं, बाद में बनाना बस मुमकिन हो जाता है।
JXL एनिमेशन ढो सकता है; JPG फ़ाइल एक ही फ़्रेम है। बाहर ऐसी फ़ाइल आती है जिसमें एक तस्वीर है, और वह ऐसे फ़ॉर्मेट में है जो इससे ज़्यादा सँभाल सकता था।
JXL को कुछ ही ब्राउज़र पढ़ पाते हैं। इस लिहाज़ से दोनों में यही कम जगह चलने वाला है। भेजने से पहले देख लीजिए कि पाने वाला इसे लेता भी है या नहीं।
GIMP JPG और JXL — दोनों पढ़ लेता है, इसलिए आप नतीजे को असली फ़ाइल के बग़ल में रखकर देख सकते हैं, बिना दूसरा प्रोग्राम खोले।
नतीजा असली से बड़ा होगा और बेहतर नहीं। JPG पहले ही बारीक़ी फेंक चुका है और JXL बचे हुए को बिना और फेंके सँभालता है: यह आगे का नुक़सान रोकता है, पहले वाला लौटाता नहीं।
JPG Joint Photographic Experts Group का फ़ॉर्मेट है, जो 1992 में आया। यह हर चैनल पर 8 बिट में दर्ज करता है।
JXL Joint Photographic Experts Group का है और 2021 से चला आ रहा है, और ISO/IEC 18181 में तय किया गया है। GIMP और ImageMagick इस फ़ॉर्मेट को पढ़ लेते है।
JPG 1992 में आया और JXL 2021 में। किसी को सौंपने के लिए आम तौर पर पुराना वाला ज़्यादा सुरक्षित रहता है; नया वाला वही काम कम बाइट में कर देता है।
नहीं। यह कन्वर्ज़न पूरी तरह आपके ब्राउज़र में होता है, इसलिए फ़ाइल आपके डिवाइस से बाहर नहीं जाती। आप ख़ुद जाँच सकते हैं: डेवलपर टूल्स का नेटवर्क टैब खोलिए और कुछ बदल कर देखिए। आपको पेज ख़ुद दिखेगा और आँकड़ों तथा विज्ञापन के वे अनुरोध दिखेंगे जिनसे इस सेवा का ख़र्च निकलता है — और एक भी ऐसा अनुरोध नहीं जो आपकी फ़ाइल साथ ले जा रहा हो। इस जोड़ी के पीछे jSquash है, तस्वीरों के संदर्भ कोडेक के WebAssembly संस्करण; आपका ब्राउज़र इसे एक बार उतारता है और फिर सहेज कर रखता है।
हाँ। न खाता, न वॉटरमार्क, और न कोई रोज़ का कोटा जो ख़त्म हो: यह आपकी अपनी मशीन पर चलता है, इसलिए आप जितनी बार चाहें लौट सकते हैं। ब्राउज़र 100 MB तक की फ़ाइलें सँभालता है, एक बार में 100। jSquash आपकी अपनी मशीन पर उतरता है और वहीं चलता है — इसीलिए उस पर कोई गिनती नहीं है।
JXL कंप्रेस करता है, इसलिए कुछ डेटा जाता है। तयशुदा सेटिंग पर यह पकड़ में नहीं आता; पक्का करना हो तो गुणवत्ता बढ़ा दीजिए।
नतीजा असली से बड़ा होगा और बेहतर नहीं। JPG पहले ही बारीक़ी फेंक चुका है और JXL बचे हुए को बिना और फेंके सँभालता है: यह आगे का नुक़सान रोकता है, पहले वाला लौटाता नहीं।
JXL को कुछ ही ब्राउज़र पढ़ पाते हैं। इस लिहाज़ से दोनों में यही कम जगह चलने वाला है। भेजने से पहले देख लीजिए कि पाने वाला इसे लेता भी है या नहीं।
JXL में कैप्शन, क्रेडिट और कीवर्ड वाले IPTC फ़ील्ड और GPS निर्देशांक के लिए जगह नहीं है, इसलिए वह JPG फ़ाइल से आगे नहीं जाता। असली फ़ाइल फेंकने से पहले यह देख लेना काम आता है — और अगर फेंकना ही मक़सद था, तो यह जान लेना काम आता है।
इस पेज पर JPG और JXL के बारे में जो कहा गया है, वह जाँचा जा सकता है, और ये रहे वे दस्तावेज़ जो उसे तय करते हैं।