इमेज कंप्रेशन गाइड: JPG·PNG·WebP का उपयोग के हिसाब से चुनाव

2026-04-13 को प्रकाशित 8 मिनट पढ़ें

सारांश (TL;DR)

पिछले हफ़्ते मैंने एक 4.2 MB की बिल्ली की तस्वीर Squoosh पर डाली और WebP क्वालिटी 80 पर एक्सपोर्ट किया। नतीजा 380 KB — यानी 91% की कमी। ईमानदारी से कहूँ तो फ़ोन की स्क्रीन पर मैं असली और कंप्रेस की गई तस्वीर में कोई फ़र्क नहीं बता पाया। यही लॉसी कंप्रेशन का असली काम है। हर बार जब मैं यह बात भूल जाता हूँ, किसी ब्लॉग को खोलकर 2 MB की हीरो JPG को LTE पर तीन सेकंड लोड होते देखता हूँ और वही सबक फिर से मिल जाता है।

इमेज फ़ॉर्मैट का चुनाव “सबसे अच्छा कौन है” से नहीं, बल्कि “किस काम के लिए है” से तय होता है। कंटिन्युअस-टोन वाली फ़ोटो के लिए लॉसी फ़ॉर्मैट — JPEG, लॉसी WebP और AVIF — फ़ाइलें छोटी रखते हैं, और आँखों को फ़र्क बहुत कम दिखता है। एक जैसी विज़ुअल क्वालिटी पर WebP आमतौर पर JPEG से लगभग 25–35% छोटी फ़ाइलें देता है, और AVIF एनकोडर सेटिंग के हिसाब से JPEG से 40–50% तक छोटा उतरता है। दूसरी ओर लोगो, आइकन, स्क्रीनशॉट और वे इमेज जहाँ तीखे किनारे या टेक्स्ट की पठनीयता ज़रूरी है, उनके लिए PNG, लॉसलेस WebP और TIFF जैसे लॉसलेस फ़ॉर्मैट सुरक्षित हैं। अगर ट्रांसपेरेंसी और एनिमेशन दोनों चाहिए तो WebP, APNG और AVIF मुख्य विकल्प हैं। ब्राउज़र सपोर्ट 2026 की शुरुआत तक काफ़ी व्यापक है: WebP Chrome 32 (2014), Firefox 65 और Safari 14 (late 2020) से चल रहा है, और AVIF Chrome 85 (अगस्त 2020), Firefox 93 (अक्टूबर 2021) व Safari 16 (सितंबर 2022) से सपोर्ट करता है। एक सीधा बेसलाइन है — “वेक्टर लोगो के लिए SVG, फ़ोटो के लिए WebP या AVIF, स्क्रीनशॉट के लिए PNG”, और पुराने माहौल के लिए <picture> में JPEG फ़ॉलबैक।

पृष्ठभूमि

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

JPEG 1992 में मानकीकृत हुआ था और 8×8 पिक्सेल ब्लॉक पर डिस्क्रीट कोसाइन ट्रांसफ़ॉर्म (DCT) इस्तेमाल करता है। WebP VP8 वीडियो कोडेक की इंट्रा-फ़्रेम तकनीकों पर बना है, और AVIF AV1 के इंट्रा-फ़्रेम टूलसेट का उपयोग करता है। दोनों JPEG से काफ़ी आधुनिक हैं — बड़ी ब्लॉक साइज़, दिशात्मक प्रेडिक्शन और बेहतर एंट्रॉपी कोडिंग के साथ। PNG एक अलग ही जाति का है: यह लॉसलेस फ़ॉर्मैट है जो deflate कंप्रेशन परिवार का उपयोग करता है, और इसमें अल्फ़ा ट्रांसपेरेंसी व पैलेट-आधारित इंडेक्स्ड कलर बिल्ट-इन हैं। PNG कभी डेटा नहीं गिराता, लेकिन फ़ोटो कंटेंट में इस शुद्धता की क़ीमत बहुत बड़ी फ़ाइलों के रूप में चुकानी पड़ती है।

एक संबंधित विचार है प्रोग्रेसिव डिकोडिंग। प्रोग्रेसिव JPEG और इंटरलेस्ड PNG दर्शक को कम-रेज़ोल्यूशन वाला संस्करण तुरंत दिखा देते हैं और बाइट आने के साथ तेज़ होते जाते हैं। SVG, आख़िर में, कोई रास्टर इमेज फ़ॉर्मैट है ही नहीं — यह एक वेक्टर डिस्क्रिप्शन है, और इसकी साइज़ shapes की संख्या और स्रोत टेक्स्ट के कंप्रेशन (gzip और brotli SVG सोर्स पर बहुत प्रभावी हैं) पर निर्भर करती है।

तुलना और डेटा

फ़ॉर्मैटलॉसीलॉसलेसट्रांसपेरेंसीएनिमेशनफ़ोटो कंप्रेशन औसतन2025 ब्राउज़र सपोर्ट
JPEGहाँनहींनहींनहींलगभग 10:1सभी ब्राउज़र
PNGनहींहाँहाँAPNG एक्सटेंशनलगभग 2–3:1सभी ब्राउज़र
WebPहाँहाँहाँहाँJPEG से लगभग 25–35% छोटाSafari 14 (2020) के बाद लगभग सब जगह
AVIFहाँहाँहाँहाँJPEG से लगभग 40–50% छोटाChrome 85+, Firefox 93+, Safari 16+
GIFहाँ (256 रंगों का पैलेट)नहीं1-बिट हीहाँफ़ोटो के लिए ख़राबसभी ब्राउज़र

इन आँकड़ों को सामान्य रुझान मानें। असल कंप्रेशन स्रोत, एनकोडर, प्रीसेट और टारगेट क्वालिटी पर बहुत निर्भर करता है। वही JPEG क्वालिटी 85 पर और क्वालिटी 60 पर 3–4x के फ़र्क में आ सकती है, और तेज़ प्रीसेट इस्तेमाल करने पर AVIF की बढ़त घट जाती है। Google और Mozilla ने 2019 से 2023 के बीच जो बेंचमार्क निकाले थे, उनमें WebP की JPEG पर लगभग 26%–34% बचत और AVIF की 40%–50% बचत दर्ज थी — लेकिन ये आँकड़े धीमे प्रीसेट और ट्यून किए गए क्वालिटी टारगेट मानते हैं, वन-क्लिक डिफ़ॉल्ट नहीं।

एक और आयाम है एनकोड और डिकोड की लागत। JPEG किसी भी डिवाइस पर एक मिलीसेकंड के हिस्से में डिकोड हो जाता है। WebP लगभग उतना ही। AVIF डिकोड CPU पर भारी है, और उच्च-क्वालिटी प्रीसेट पर एनकोड एक फ़ोटो पर कई सेकंड ले सकता है।

वास्तविक परिदृश्य

परिदृश्य 1 — ब्लॉग थंबनेल और हीरो इमेज। मेरी अपनी साइट का हीरो 1.8 MB भेजा जा रहा था। WebP क्वालिटी 82 पर दोबारा एक्सपोर्ट करने पर वह 210 KB हो गया, और Lighthouse के throttled 4G प्रोफ़ाइल पर LCP 2.4s से गिरकर 1.1s पर आ गया। WebP को डिफ़ॉल्ट रखें और बहुत पुराने माहौल के लिए <picture> में JPEG फ़ॉलबैक दें। हमेशा एक्सपोर्ट की गई इमेज को वास्तविक CSS डिस्प्ले चौड़ाई से मिलाकर रीसाइज़ करें।

परिदृश्य 2 — लोगो और आइकन। अगर वेक्टर सोर्स है तो पहले SVG एक्सपोर्ट करें। मैंने एक बार एक लैंडिंग पेज देखा जहाँ लाल ब्रांड लोगो JPEG क्वालिटी 75 पर एक्सपोर्ट किया गया था; हर ग्लिफ़ के किनारे गुलाबी हेलो में बह रहे थे। 4:2:0 क्रोमा सबसैम्पलिंग गहरे बैकग्राउंड पर लाल किनारों को सबसे पहले बर्बाद करती है। अगर केवल रास्टर आर्ट है, तो PNG या लॉसलेस WebP चुनें। लोगो पर लॉसी कंप्रेशन को ऑप्टिमाइज़ेशन नहीं, रेड फ़्लैग मानें।

परिदृश्य 3 — स्क्रीनशॉट और UI कैप्चर। स्क्रीनशॉट का डिफ़ॉल्ट PNG होना चाहिए। ब्राउज़र क्रोम, कोड स्निपेट्स और देवनागरी व CJK फ़ॉन्ट — ये सब JPEG आर्टिफ़ैक्ट्स दिखाते हैं। मैंने यह तब सीखा जब एक डॉक रिव्यूअर ने लगातार दो PR पर “धुंधला monospace फ़ॉन्ट” फ़्लैग किया। फ़ाइल छोटी करनी हो तो pngquant (macOS पर brew install pngquant) का उपयोग करें, पैलेट को 256 रंगों तक गिरा दें; UI स्क्रीनशॉट में फ़र्क लगभग नहीं दिखेगा और फ़ाइल 4–6x छोटी हो जाती है।

परिदृश्य 4 — सोर्स मटेरियल का आर्काइव। जिन ओरिजिनल्स पर बाद में फिर से काम करना पड़ सकता है (फ़ोटोग्राफ़ी मास्टर्स, कच्चे स्कैन, प्रोडक्ट शॉट्स), उनकी TIFF या लॉसलेस WebP कॉपी कोल्ड स्टोरेज में रखें।

आम ग़लतफ़हमियाँ

“PNG हमेशा सबसे उच्च क्वालिटी होती है।” यह लॉसलेस है, मतलब परफ़ेक्ट रीप्रोडक्शन, लेकिन फ़ोटो के लिए यही शुद्धता बहुत बड़ी फ़ाइलें बना देती है। मोबाइल पर मल्टी-मेगाबाइट फ़ोटो Core Web Vitals और महसूस होने वाले लोड टाइम दोनों पर चोट करती हैं।

“WebP सभी ब्राउज़र में नहीं चलता।” 2020 के अंत में Safari 14 के बाद से हर मुख्य ब्राउज़र में सपोर्टेड है। अगर वाक़ई लेगेसी सपोर्ट चाहिए तो <picture> में JPEG फ़ॉलबैक साफ़ समाधान है।

“AVIF जादू है।” कंप्रेशन दक्षता बहुत अच्छी है, लेकिन एनकोडिंग JPEG और WebP से काफ़ी धीमी। मेरी M2 MacBook Air पर avifenc --speed 4 से एक 2400×1600 फ़ोटो 5–9 सेकंड में, और --speed 0 पर 30 सेकंड से ज़्यादा लेती है। AVIF बैच पाइपलाइन और बिल्ड-टाइम ऑप्टिमाइज़ेशन के लिए ज़्यादा जम जाता है, हर यूज़र अपलोड को हॉट पाथ पर फिर से एनकोड करने के लिए नहीं।

“बस JPEG इस्तेमाल कर लो।” 2015 तक यह उचित था, लेकिन आधुनिक WebP और AVIF तुलनीय क्वालिटी पर छोटी फ़ाइलें देते हैं, वह भी लगभग सार्वभौमिक सपोर्ट के साथ। नई पाइपलाइन्स में WebP को बेसलाइन मानें, JPEG को नहीं।

“हाई-क्वालिटी सेटिंग्स हमेशा फ़ायदेमंद होती हैं।” JPEG या WebP में क्वालिटी 85 से ऊपर फ़ाइल साइज़ बोध-क्वालिटी से तेज़ी से बढ़ती है। क्वालिटी 85 और 95 का फ़र्क दर्शकों को शायद ही दिखे, पर फ़ाइल दोगुनी हो सकती है।

“अच्छे कंप्रेशन से रीसाइज़िंग बेकार हो जाती है।” इमेज डिलीवरी में सबसे बड़ी बचत आमतौर पर सही साइज़ की इमेज भेजने से होती है, कंप्रेशन ट्यूनिंग से नहीं।

चेकलिस्ट

  1. क्या सोर्स वेक्टर है? अगर हाँ, तो SVG में सेव करें।
  2. क्या ट्रांसपेरेंसी चाहिए?
    • हाँ और कंटेंट फ़ोटोग्राफ़िक है: अल्फ़ा वाला लॉसी WebP या AVIF।
    • हाँ और कंटेंट लोगो या आइकन है: PNG या लॉसलेस WebP।
  3. क्या एनिमेशन चाहिए? एनिमेटेड WebP, APNG या AVIF। GIF का 256-रंग पैलेट फ़ोटो के लिए ख़राब है।
  4. क्या कंटेंट फ़ोटो या ग्रेडिएंट-भारी है? डिफ़ॉल्ट लॉसी WebP, और जहाँ बैंडविड्थ मायने रखता है वहाँ AVIF जोड़ें।
  5. क्या कंटेंट स्क्रीनशॉट या टेक्स्ट-भारी UI है? PNG या लॉसलेस WebP।
  6. क्या अधिकतम संगतता चाहिए? <picture> एलिमेंट के साथ AVIF → WebP → JPEG के क्रम में सोर्स दें।

संबंधित टूल

इन ट्रेड-ऑफ़ को आप Patrache Studio इमेज कंप्रेसर पर सीधे आज़मा सकते हैं, जो relatedToolUrl में दिया है। इमेज आमतौर पर बड़े एसेट पाइपलाइन का हिस्सा होती हैं, इसलिए साथी गाइड पढ़ना मददगार है: ब्राउज़र में PDF मर्ज और स्प्लिट उस समय की बात करती है जब आपकी इमेज कॉन्ट्रैक्ट या स्कैन बंडल के अंदर पहुँच जाती हैं, और QR कोड सुरक्षा तब काम आती है जब आपकी इमेज में प्रोडक्ट पैकेजिंग या पोस्टर पर स्कैन करने योग्य QR कोड होते हैं।

संदर्भ

संबंधित टूल

tools.patrache.studio/image/compress/