छवि कम्प्रेसर

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

1. ऊपर एक या अधिक छवियाँ चुनें या छोड़ें।
2. गुणवत्ता स्लाइडर समायोजित करें (कम = छोटी फ़ाइल, अधिक संपीड़न)।
3. छवियाँ संपीड़ित होती हैं आपके ब्राउज़र में · कुछ भी अपलोड नहीं होता।
4. संपीड़ित छवियों को अलग-अलग या एक साथ डाउनलोड करें।

छवियों को क्यों संपीड़ित करें?

बड़ी छवियाँ वेबसाइटों को धीमा करती हैं, बाउंस दर बढ़ाती हैं और आपकी Google रैंकिंग को नुकसान पहुँचाती हैं। छवियों को संपीड़ित करने से न्यूनतम दृश्य गुणवत्ता हानि के साथ फ़ाइल का आकार 50-80% तक कम हो जाता है। यह वेब डेवलपर्स, ब्लॉगर्स, ई-कॉमर्स स्टोर्स और ऑनलाइन सामग्री प्रकाशित करने वाले किसी भी व्यक्ति के लिए आवश्यक है। छोटी छवियाँ मोबाइल उपकरणों पर बैंडविड्थ भी बचाती हैं और Core Web Vitals स्कोर को बेहतर बनाती हैं।

«छवि संपीड़न» का असली अर्थ क्या है

छवि संपीड़न दो मौलिक रूप से भिन्न क्रियाओं को समेटता है जो एक ही नाम साझा करती हैं। हानिकारक संपीड़न, जिसका उपयोग JPEG और हानिकारक WebP करते हैं, उन छवि-डेटा को त्यागता है जिन्हें मानवीय आँख देख पाने की संभावना नहीं रखती (छाया में सूक्ष्म ग्रेडेशन, उच्च-आवृत्ति शोर, मानव-दृष्टि के अनुकूल वर्ण-बनाम-चमक अनुपात के लिए क्रोमा-सबसैम्पलिंग)। आउटपुट इनपुट से छोटा होता है पर बिट-दर-बिट पुनर्निर्माण नहीं किया जा सकता। निर्बाध संपीड़न, जिसका उपयोग PNG, GIF, TIFF-LZW और निर्बाध WebP करते हैं, सटीक पिक्सेल-डेटा को DEFLATE (LZ77 + हफमैन) जैसे एल्गोरिथ्मों से अधिक संक्षिप्त रूप में कूटबद्ध करता है। आउटपुट छोटा होता है और विसंपीड़न मूल को बाइट-दर-बाइट पुनरुत्पन्न करता है। कौन सही है यह छवि पर निर्भर करता है: फ़ोटोग्राफ़ हानिकारक संपीड़न को बहुत अच्छी तरह झेलती हैं क्योंकि उनकी सामग्री बनावट से भरी होती है जिसे आँख पिक्सेल-स्तर पर नहीं पकड़ती; जबकि लोगो, स्क्रीनशॉट और तीखे रंग-संक्रमण वाले ग्राफ़िक्स निर्बाध संपीड़न मांगते हैं क्योंकि हर पिक्सेल जानबूझकर रखा गया है।

JPEG संपीड़क में गुणवत्ता सेटिंग्स (इस उपकरण का स्लाइडर, 10-100%) DCT चरण के बाद लागू क्वांटाइज़ेशन तालिकाओं को नियंत्रित करती हैं। गुणवत्ता 100 पर तालिकाएँ शायद ही किसी आवृत्ति-गुणांक को पूर्णांकित करती हैं; गुणवत्ता 50 पर वे आक्रामक रूप से पूर्णांकित करती हैं। अधिक गुणवत्ता का अर्थ है बड़ी फ़ाइलें और बारीक विवरण; कम गुणवत्ता का अर्थ है छोटी फ़ाइलें और समतल क्षेत्रों में दिखाई देने वाले ब्लॉक-आकार के विरूपण। डिफ़ॉल्ट 60% वेब-उपयोग के लिए मीठे स्थान पर बैठता है: सामान्यतः फ़ाइल आकार में 50 से 80% की कमी और किसी सामान्य स्क्रीन पर कोई अनुभूत बदलाव नहीं। प्रिंट या बड़ी-स्क्रीन के काम के लिए 80-90% तक बढ़ाएँ। थंबनेल या मेल-अनुकूल संस्करण के लिए 30-50% ठीक है।

PNG के लिए «गुणवत्ता» स्लाइडर सामान्य अर्थ में लागू नहीं होता क्योंकि PNG हमेशा निर्बाध है। यह उपकरण PNG इनपुट पर वास्तव में जो करता है वह है अधिकांश रचना-सॉफ़्टवेयर (Photoshop, Affinity, Sketch) की डिफ़ॉल्ट से अधिक मज़बूत DEFLATE पास चलाना; यह आम तौर पर बिना किसी पिक्सेल-बदलाव के 5 से 25% तक फ़ाइल आकार बचा लेता है। Format ड्रॉपडाउन PNG को JPEG या WebP में बदलने भी देता है, जो बहुत छोटी फ़ाइल के बदले निर्बाधता का सौदा करता है पर JPEG आउटपुट के लिए पारदर्शिता खो देता है और (फ़ोटोग्राफ़िक सामग्री के लिए) WebP की निर्बाधता-गारंटी खो देता है। Max Width विकल्प संपीड़न के दौरान छवि का आकार बदलता है: 4000 पिक्सेल चौड़ी एक फ़ोटो को 1920 पिक्सेल पर लाने से किसी भी संपीड़न के चलने से पहले ही कच्चे पिक्सेल-गिनती में 75% की बचत होती है, और यह गुणवत्ता-कमी के साथ जुड़ जाती है।

यह उपकरण भीतर से कैसे काम करता है

संपीड़न-इंजन है Donald Wong का browser-image-compression (GitHub: Donaldcwl/browser-image-compression, MIT लाइसेंस)। यह एक शुद्ध JavaScript लाइब्रेरी है, मिनिफ़ाइड लगभग 95 KB, जो ब्राउज़र के तीन आदिम-कार्यों को लपेटती है: बाइट पढ़ने के लिए File API, JPEG/WebP छवियों को डिकोड, रिसाइज़ और पुनः-एनकोड करने के लिए Canvas API (या उपलब्ध होने पर OffscreenCanvas), और PNG को बिना Canvas के संभालने के लिए UZIP (एक छोटी DEFLATE लाइब्रेरी)। जब आप कोई छवि गिराते हैं, ब्राउज़र बाइट लाइब्रेरी को सौंप देता है; लाइब्रेरी इनपुट-फ़ॉर्मेट और अनुरोधित आउटपुट के आधार पर रास्ता चुनती है।

JPEG और WebP इनपुट के लिए रास्ता है: कैनवस पर डिकोड करना, वैकल्पिक रूप से कॉन्फ़िगर की गई Max Width पर रिसाइज़ करना, फिर canvas.toBlob(mimeType, गुणवत्ता/100) को कॉल करना। ब्राउज़र का अंतर्निहित JPEG या WebP एनकोडर असली क्वांटाइज़ेशन और हफमैन कोडिंग करता है। गुणवत्ता आपके स्लाइडर का मान 100 से विभाजित है, जिसे दूसरा तर्क बनाकर पास किया जाता है। PNG को PNG के रूप में बनाए रखने वाले इनपुट के लिए लाइब्रेरी Canvas को पूरी तरह छोड़ देती है (Canvas के माध्यम से एक दौर-यात्रा निर्बाध डेटा को व्यर्थ ही पुनः-रास्टराइज़ करेगी) और इसके बजाय PNG फ़ाइल के IDAT खंडों पर सीधे UZIP चलाती है, अधिकतम संपीड़न-प्रयास के साथ। यही कारण है कि यहाँ PNG-से-PNG संपीड़न वास्तव में निर्बाध है: पिक्सेल डेटा कभी डिकोड और पुनः-एनकोड नहीं होता, केवल DEFLATE आवरण को कसा जाता है।

जब OffscreenCanvas समर्थित है (आधुनिक Chrome, Edge, Safari, Firefox), तब भारी डिकोड-रिसाइज़-एनकोड का काम Web Worker के भीतर चलता है, जिससे मुख्य UI थ्रेड उत्तरदायी बनी रहती है। आप 20 तस्वीरों का बैच गिरा सकते हैं और हर एक के संसाधित होते समय पृष्ठ स्क्रॉल करते रह सकते हैं। पुराने ब्राउज़रों पर लाइब्रेरी मुख्य थ्रेड पर लौट आती है, जो काम तो करता है पर बड़े कार्यों के दौरान पृष्ठ को अवरुद्ध करता है। पूरी पाइपलाइन आपके टैब के भीतर चलती है। लाइब्रेरी पहली विज़िट पर CDN से एक बार लोड होती है (लगभग 95 KB मिनिफ़ाइड), बाद में कैश हो जाती है। फ़ाइल सामग्री कभी ब्राउज़र नहीं छोड़ती। एक बैच संपीड़न करते समय DevTools के नेटवर्क टैब को खोलें और आपको लाइब्रेरी की एक-बार फ़ेच दिखेगी, बाकी कुछ नहीं।

छवि-संपीड़न फ़ॉर्मेट का संक्षिप्त इतिहास

• DCT, 1972-1974। Nasir Ahmed ने 1972 में डिस्क्रीट कोसाइन ट्रांसफ़ॉर्म को छवि-संपीड़न पद्धति के रूप में प्रस्तावित किया; औपचारिक एल्गोरिथ्म 1974 में T. Natarajan और K. R. Rao के साथ प्रकाशित हुआ। यह एक गणितीय रूपांतरण आज दुनिया की हर JPEG, MPEG और H.26x वीडियो फ़ाइल के नीचे बैठा है।
• JPEG, 1992। Joint Photographic Experts Group (1986 में स्थापित) ने 1992 में JPEG को ITU-T T.81 / ISO/IEC 10918-1 के रूप में मानकीकृत किया। 8x8 DCT ब्लॉक, वैकल्पिक क्रोमा-सबसैम्पलिंग के साथ YCbCr रंग-स्थान, मानव-दृष्टि के अनुरूप ट्यून की गई क्वांटाइज़ेशन-तालिकाएँ। वह फ़ॉर्मेट जिसने फ़ोटो-समृद्ध वेब को संभव बनाया।
• PNG, 1996। Unisys के LZW पेटेंट दावों ने खुले वेब को धमकाने के बाद, GIF को बदलने हेतु IETF में RFC 2083 के रूप में बनाया गया। DEFLATE (LZ77 + हफमैन) संपीड़न, हमेशा निर्बाध, पूर्ण अल्फा-पारदर्शिता, बिना पेटेंट-बोझ। तीसरा संस्करण-स्पेक (W3C, 2023) ने HDR, APNG एनिमेशन और EXIF मेटाडेटा को आधिकारिक रूप से जोड़ा।
• WebP, 2010। Google ने WebP को VP8 वीडियो-कोडेक की इंट्रा-फ़्रेम कोडिंग पर आधारित एक स्थिर-छवि फ़ॉर्मेट के रूप में जारी किया। हानिकारक WebP तुलनीय दृश्य-गुणवत्ता पर JPEG से 25-34% छोटा है; निर्बाध WebP PNG से लगभग 26% छोटा है। अपनाव में एक दशक लगा; 2026 तक दुनिया के 96% से अधिक ब्राउज़र इसका समर्थन करते हैं।
• AVIF, 2019। Alliance for Open Media ने AVIF को AV1 वीडियो-कोडेक के स्थिर-छवि संस्करण के रूप में जारी किया। तुलनीय गुणवत्ता पर JPEG से लगभग 50% छोटा। ब्राउज़र-समर्थन अब 95% से अधिक है, परंतु रोज़मर्रा के रचना-उपकरणों (Photoshop, Word, Slack) में एनकोडर-समर्थन पीछे चल रहा है। Squoosh और ImageMagick आज AVIF उत्पन्न कर सकते हैं; अधिकांश कैमरे और फ़ोन नहीं।
• HEIC, 2017। Apple ने HEIF/H.265 आधारित HEIC को iPhone के डिफ़ॉल्ट फ़ोटो-फ़ॉर्मेट के रूप में अपनाया। समतुल्य JPEG से लगभग आधा आकार। रॉयल्टी-बाधित, इसलिए खुले वेब पर शायद ही परोसा जाता है। अधिकांश ऑनलाइन अपलोडर (इस उपकरण सहित) HEIC को केवल डेस्कटॉप पर JPEG में रूपांतरण के बाद ही स्वीकारते हैं; गैर-Apple प्राप्तकर्ता को फ़ोन-फ़ोटो भेजने का यही दैनिक प्रवाह है।

समर्थित प्रारूप

• JPEG · तस्वीरों और जटिल छवियों के लिए सर्वोत्तम। समायोज्य गुणवत्ता के साथ हानिपूर्ण संपीड़न।
• PNG · ग्राफिक्स, लोगो और पारदर्शिता वाली छवियों के लिए सर्वोत्तम।
• WebP · Google का आधुनिक प्रारूप, तुलनीय गुणवत्ता पर JPEG/PNG से छोटी फ़ाइलें प्रदान करता है।

वास्तविक-दुनिया संपीड़न-प्रवाह

• ब्लॉग और वेबसाइट छवियाँ। किसी फ़ोन से सीधे आई एक 2 MB की JPEG बनाम 250 KB की संपीड़ित JPEG: सामान्य स्क्रीन पर मानवीय आँख को समान, परंतु छोटी फ़ाइल लगभग 8 गुना तेज़ लोड होती है। Core Web Vitals (LCP) स्कोर सीधे बेहतर होते हैं। अनेक तस्वीरों वाले अधिकांश पृष्ठ Lighthouse में सबसे बड़ा प्रदर्शन-लाभ छवि-संपीड़न से देखते हैं, JavaScript या CSS अनुकूलन से नहीं।
• सोशल मीडिया अपलोड। Instagram, Twitter, Facebook, LinkedIn सब अपलोड पर अपने स्वयं के एल्गोरिथ्मों से छवियों को पुनः-संपीड़ित करते हैं। पहले संपीड़ित करना आपको यह नियंत्रण देता है कि क्या बलिदान हो; कच्ची तस्वीरें अपलोड करना उन निर्णयों को प्लेटफ़ॉर्म पर छोड़ देता है, अक्सर दृश्य-गिरावट के साथ।
• ईमेल अनुलग्नक। अधिकांश प्रदाता प्रति-संदेश अनुलग्नकों को 25 MB पर सीमित रखते हैं (Gmail, Outlook, Apple Mail)। लगभग 50 MB के फ़ोटो-फ़ोल्डर को लगभग 10 MB तक संपीड़ित करना सब कुछ एक ही ईमेल में भेजने देता है, बजाय कई संदेशों में बाँटने या क्लाउड-शेयर लिंक पर जाने के।
• ई-कॉमर्स उत्पाद-तस्वीरें। सैकड़ों या हज़ारों फ़ोटो वाले उत्पाद-कैटलॉग बड़े CDN-बैंडविड्थ बिल और धीमे पृष्ठ-लोड का कारण बनते हैं। पूरी पुस्तकालय का संपीड़न दोनों को घटाता है। Shopify, Etsy और Amazon विक्रेता अपलोड से पहले संपीड़न नियमित रूप से करते हैं ताकि होस्टिंग-लागत कम हो और सर्च-रैंकिंग बेहतर हो।
• स्क्रीनशॉट-प्रधान पोर्टफ़ोलियो। UI डिज़ाइन पोर्टफ़ोलियो PNG-प्रधान होते हैं क्योंकि स्क्रीनशॉट में तीखे रंग-संक्रमण होते हैं जहाँ JPEG विरूपण दिखेंगे। कसी हुई DEFLATE के माध्यम से PNG-से-PNG आम तौर पर बिना किसी पिक्सेल-बदलाव के 10-20% बचा देता है, जो ऐसी डिज़ाइनर पोर्टफ़ोलियो साइटों के लिए उपयोगी है जिन्हें रेंडरिंग-गुणवत्ता त्याग किए बिना तेज़ रहना है।
• अभिलेखीय आकार-कमी। किसी फ़ोन की 12 मेगापिक्सेल फ़ोटो किसी ऐसे पारिवारिक-साझा एल्बम के लिए ज़रूरत से अधिक है जो सिर्फ़ स्क्रीन पर ही देखी जाएगी। 4 मेगापिक्सेल पर 80% गुणवत्ता में पुनः-आकार करें: परिणाम हर उस उपकरण पर समान दिखेगा जो उसे देखेगा, और अभिलेख मूल आकार का पाँचवाँ हिस्सा बन जाता है। मूल फ़ाइलें स्रोत डिस्क पर सुरक्षित रहती हैं; संपीड़ित संस्करण साझा या बैकअप में जाते हैं।

सामान्य अड़चनें और उनका अर्थ

• JPEG को बार-बार पुनः-संपीड़ित करना उसे ख़राब करता है। हर JPEG-सेव DCT क्वांटाइज़ेशन-चरण को फिर चलाती है, ऐसा विवरण खोती है जो आप कभी वापस नहीं पा सकते। पहली पास में हानि सूक्ष्म होती है, तीसरी या चौथी तक स्पष्ट। हमेशा अपने पास उपलब्ध सबसे उच्च-गुणवत्ता वाले स्रोत से ही संपीड़न करें (कैमरे का मूल फ़ाइल, आपके डिज़ाइन-उपकरण से निर्यात), पिछली सप्ताह के पूर्व-संपीड़ित JPEG से नहीं। यदि समायोजन की ज़रूरत हो, PNG या TIFF में मास्टर-कॉपी रखें।
• PNG से JPEG पारदर्शिता खो देता है। JPEG के फ़ॉर्मेट-विनिर्देश में अल्फा-चैनल बिल्कुल नहीं है। PNG को JPEG में बदलते समय कोई भी पारदर्शी पिक्सेल ठोस सफेद (या आपके एनकोडर जिसे प्रतिस्थापित करे) बन जाता है। लोगो, आइकन, पारदर्शी पृष्ठभूमि वाले स्क्रीनशॉट या किसी भी अल्फा-चैनल वाले ग्राफ़िक के लिए PNG में रहें या WebP पर जाएँ, दोनों पारदर्शिता संरक्षित रखते हैं।
• JPEG से PNG फ़ाइल को बड़ा बनाता है। PNG का DEFLATE संपीड़न चिकने ग्रेडिएंट और बड़े ठोस क्षेत्रों में महान है, और JPEG-संपीड़न द्वारा छोड़े गए उच्च-आवृत्ति शोर-पैटर्न पर बहुत बुरा। JPEG को PNG में बदलने से अक्सर फ़ाइल-आकार दोगुना या तीनगुना हो जाता है और कोई गुणवत्ता-लाभ नहीं होता। यदि JPEG से निर्बाधता चाहिए तो बहुत देर हो चुकी है: मूल जानकारी जा चुकी है। रूपांतरण तब ही समझ रखता है जब आपको विशेष रूप से PNG की पारदर्शिता चाहिए या ऐसा उपकरण जो JPEG स्वीकार न करे।
• EXIF मेटाडेटा डिफ़ॉल्ट रूप से हटा दिया जाता है। browser-image-compression लाइब्रेरी पुनः-संपीड़न के दौरान डिफ़ॉल्ट रूप से EXIF मेटाडेटा (कैमरा-जानकारी, GPS निर्देशांक, कैप्चर-तिथि, ICC रंग-प्रोफ़ाइल) छोड़ देती है। वेब-उपयोग के लिए यह आम तौर पर खूबी है (GPS निर्देशांकों का रिसाव असली गोपनीयता समस्या है)। मेटाडेटा बरकरार रखकर अभिलेखीकरण करने वाले फ़ोटोग्राफ़रों के लिए यह उपकरण उचित नहीं; ImageOptim या स्पष्ट «मेटाडेटा संरक्षित करें» ध्वज वाले jpegtran जैसे डेस्कटॉप-संपीड़क का प्रयोग करें।
• रंग-प्रोफ़ाइल नहीं बच सकते। एक एम्बेडेड ICC रंग-प्रोफ़ाइल (sRGB, Adobe RGB, ProPhoto) डिस्प्ले को बताती है कि पिक्सेल-मानों की व्याख्या कैसे करें। Canvas-आधारित पुनः-एनकोडिंग एम्बेडेड प्रोफ़ाइल को त्याग सकती है और आउटपुट को sRGB के रूप में टैग कर सकती है। सामान्य स्क्रीन-उपयोग के लिए यह ठीक है क्योंकि लगभग सब कुछ वैसे भी sRGB है। प्रिंट-प्रिप काम, रंग-प्रबंधित फ़ोटो-तैयारी या व्यापक-गामा डिलीवरेबल्स के लिए ऐसा रंग-जागरूक उपकरण (Photoshop का «Export As», Affinity, RawTherapee) उपयोग करें जो प्रोफ़ाइल-डेटा को स्पष्ट रूप से संरक्षित करता है।
• बहुत बड़ी छवियाँ मोबाइल-ब्राउज़र टैब को क्रैश कर सकती हैं। किसी छवि को Canvas में डिकोड करने के लिए उसके आयामों के अनुपात में RAM चाहिए: एक 24-मेगापिक्सेल फ़ोटो (6000x4000 पिक्सेल) के लिए सिर्फ़ RGBA पिक्सेल-बफ़र हेतु लगभग 96 MB चाहिए, साथ ही एनकोडर का कार्यकारी मेमोरी। 4 GB RAM वाले मोबाइल डिवाइसों पर OS एनकोड पूरा होने से पहले टैब बंद कर सकता है। इनपुट को छोटा करें या बहुत बड़ी तस्वीरों के लिए डेस्कटॉप-ब्राउज़र उपयोग करें।

गोपनीयता: छवियाँ आपके डिवाइस पर रहती हैं

हर क्लाउड छवि-संपीड़क (TinyPNG, Compressor.io, Optimizilla, Smallpdf के छवि-उपकरण, Pixlr का संपीड़न-एंडपॉइंट, और दर्जनों «ऑनलाइन छवि संपीड़ित करें» सेवाएँ) आपकी फ़ाइल को ऑपरेटर के सर्वर पर अपलोड करते हैं, अपने संपीड़न-एल्गोरिथ्म चलाते हैं, और छोटी छवि को डाउनलोड के रूप में लौटाते हैं। गोपनीयता-निहितार्थ साधारण नहीं हैं क्योंकि तस्वीरें नियमित रूप से पहचान-योग्य सामग्री समेटती हैं: चेहरे, पृष्ठभूमि में दिखने वाले पते, आंतरिक UI या गोपनीय दस्तावेज़ों के स्क्रीनशॉट, बच्चों की तस्वीरें, निजी स्थानों में ली गई तस्वीरें। अधिकांश ऑपरेटर एक-दो घंटे के भीतर मिटाने और परिवहन में एन्क्रिप्शन की प्रतिबद्धता वाली गोपनीयता-नीतियाँ प्रकाशित करते हैं, और बड़े (TinyPNG, Smallpdf) ISO/IEC 27001 प्रमाणन धारण करते हैं। उनके पास इनका पालन करने के मज़बूत व्यावसायिक कारण हैं। पर «एक घंटे में मिटाया गया» «कभी न देखा» के बराबर नहीं है। उस घंटे के दौरान छवि-सामग्री ऑपरेटर के बुनियादी ढाँचे में रहती है, उपयुक्त अनुमति वाले किसी भी प्रक्रिया या व्यक्ति के लिए सुलभ, और लागू प्रतिधारण-नीति के अनुसार लॉग और बैकअप में दृश्यमान।

यह संपीड़क कभी कुछ अपलोड नहीं करता। browser-image-compression लाइब्रेरी पूरी तरह आपके टैब में चलती है; छवि-बाइट File API द्वारा पढ़े जाते हैं, JavaScript (या OffscreenCanvas उपलब्ध होने पर Web Worker) में संसाधित होते हैं, और संपीड़ित आउटपुट डाउनलोड-योग्य Blob के रूप में उसी टैब में लौटाया जाता है। आप अपलोड न होने का सत्यापन एक बैच संपीड़न से पहले ब्राउज़र DevTools के Network टैब को खोलकर कर सकते हैं: आपकी छवि-सामग्री वाला कोई अनुरोध जारी नहीं होगा। एकमात्र नेटवर्क-यातायात है पहली विज़िट पर CDN से लाइब्रेरी (~95 KB) की एक-बार फ़ेच, जिसके बाद लाइब्रेरी कैश हो जाती है। पेज लोड होने के बाद ब्राउज़र को एयरप्लेन मोड में डालें और संपीड़क स्थानीय फ़ाइलों पर काम करता रहता है। संवेदनशील कुछ भी समेटने वाली तस्वीरों (चेहरे, स्थान, आंतरिक स्क्रीनशॉट) के लिए ब्राउज़र-पक्षीय सौदा स्पष्ट रूप से करने योग्य है।

जब दूसरा उपकरण सही चयन हो

• स्क्रिप्टेड पाइपलाइन में 500+ छवियों का बैच-प्रसंस्करण। Node.js में sharp (मानक सर्वर-साइड छवि-लाइब्रेरी), कमांड-लाइन पर ImageMagick या GraphicsMagick, या Python में Pillow का उपयोग करें। ये उपकरण ब्राउज़र-मेमोरी की सीमाओं के बिना हज़ारों फ़ाइलों को संभालते हैं और CI जॉब्स, परिनियोजन-हुक या क्रॉन-टास्क से चलते हैं।
• बिट-समानता-सत्यापन योग्य कठोर निर्बाधता-गारंटी। PNG-से-PNG के लिए यह उपकरण वास्तव में निर्बाध है क्योंकि UZIP पिक्सेल-डेटा को नहीं छूता। क्रिप्टोग्राफ़िक-सत्यापन की मांग वाले प्रवाहों (चिकित्सकीय-इमेजिंग, क़ानूनी-साक्ष्य) के लिए ImageMagick जैसे डेस्कटॉप-उपकरण को स्पष्ट `-define png:compression-level=9` के साथ और डिकोडेड पिक्सेल-डेटा के SHA-256 सत्यापन के साथ उपयोग करें।
• प्रिंट-स्तरीय रंग-प्रोफ़ाइल संरक्षण। ICC प्रोफ़ाइल-संरक्षण, सॉफ़्ट-प्रूफ़िंग और CMYK आउटपुट के साथ प्रिंट-प्रिप कार्य के लिए Adobe Photoshop, Affinity Photo, या RawTherapee। ब्राउज़र-आधारित संपीड़न रंग-प्रबंधित प्रवाहों की गारंटी नहीं दे सकता क्योंकि Canvas sRGB में काम करता है और एम्बेडेड प्रोफ़ाइल-डेटा त्याग सकता है।
• अगली-पीढ़ी के संपीड़न हेतु AVIF आउटपुट। browser-image-compression 2026 तक AVIF आउटपुट नहीं देता। ब्राउज़र में AVIF एनकोडिंग के लिए Squoosh उपयोग करें (वह भी Google का, वह भी क्लाइंट-साइड); कमांड-लाइन AVIF के लिए libavif का avifenc उपयोग करें। AVIF तुलनीय गुणवत्ता पर JPEG से लगभग 50% छोटी फ़ाइलें उत्पन्न करता है, परंतु एनकोडर कंप्यूटेशनली महंगा है (JPEG एनकोडिंग से 10 गुना धीमा)।

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

क्या संपीड़न छवि की गुणवत्ता कम करता है?

डिफ़ॉल्ट 60% गुणवत्ता पर, अधिकांश छवियाँ मूल के लगभग समान दिखती हैं जबकि 50-80% छोटी होती हैं। अपनी आवश्यकताओं के लिए सही संतुलन खोजने के लिए स्लाइडर समायोजित करें।

क्या फ़ाइल आकार की कोई सीमा है?

प्रत्येक छवि 50 MB तक हो सकती है। चूंकि प्रसंस्करण आपके ब्राउज़र में होता है, बहुत बड़ी फ़ाइलों में आपके डिवाइस के आधार पर कुछ समय लग सकता है।

क्या मेरी छवियाँ किसी सर्वर पर अपलोड होती हैं?

नहीं। सारा संपीड़न आपके ब्राउज़र में स्थानीय रूप से होता है। आपकी छवियाँ कभी भी आपके डिवाइस से बाहर नहीं जातीं, जिससे यह पूरी तरह से निजी और सुरक्षित हो जाती है।

मुझे किस गुणवत्ता सेटिंग का उपयोग करना चाहिए?

वेब उपयोग के लिए, 60-70% आदर्श है। प्रिंट या पोर्टफोलियो के लिए, 80-90% आज़माएँ। अधिकतम संपीड़न (थंबनेल, ईमेल) के लिए, 30-50% अच्छी तरह काम करता है।

और भी सामान्य प्रश्न

मेरा PNG आउटपुट मूल से केवल थोड़ा छोटा क्यों है?

PNG निर्बाध है। बचत पूरी तरह वही पिक्सेल-डेटा के लिए कसा हुआ DEFLATE संपीड़न खोजने से आती है, जो आम तौर पर रचना-उपकरण (Photoshop, Sketch, Figma) के डिफ़ॉल्ट से 5-25% बचाती है। यदि आपकी PNG पहले से ही अच्छी तरह अनुकूलित थी, तो बहुत गुंजाइश नहीं बची। महत्वपूर्ण अतिरिक्त कमी के लिए या तो WebP में बदलें (जो पारदर्शिता रखता है और आम तौर पर PNG से 25% छोटा होता है), या JPEG में बदलने पर कुछ हानि स्वीकार करें (जो बहुत छोटा हो सकता है पर पारदर्शिता हटाता है)।

क्या यह उपकरण ऑफ़लाइन काम करता है?

पहली विज़िट के बाद, हाँ। browser-image-compression लाइब्रेरी (लगभग 95 KB मिनिफ़ाइड) पहली बार लोड होने पर ब्राउज़र द्वारा कैश की जाती है। बाद की विज़िट में संपीड़क बिना नेटवर्क-कनेक्शन के काम करता है, बशर्ते ब्राउज़र-कैश बीच में साफ़ न हुआ हो। आप पेज एक बार खोलने के बाद एयरप्लेन मोड चालू करके और किसी स्थानीय छवि को संपीड़ित करके सत्यापित कर सकते हैं।

क्या मेरा EXIF डेटा (कैमरा, GPS, कैप्चर-तिथि) सुरक्षित रहेगा?

नहीं, EXIF मेटाडेटा संपीड़न के दौरान डिफ़ॉल्ट रूप से हटा दिया जाता है। वेब-साझाकरण के लिए यह आम तौर पर वांछनीय है (GPS-निर्देशांक और कैमरा-सीरियल-नंबर लीक नहीं होने चाहिए), लेकिन मेटाडेटा बरकरार रखकर अभिलेखीकरण करने वाले फ़ोटोग्राफ़रों के लिए यह उपकरण उचित नहीं है। मेटाडेटा संरक्षित करने के लिए ImageOptim (macOS) या `-copy all` विकल्प वाले jpegtran जैसे EXIF-जागरूक डेस्कटॉप-संपीड़क का उपयोग करें।

Max Width रिसाइज़ और गुणवत्ता-कमी में क्या अंतर है?

रिसाइज़ करना छवि के पिक्सेल-आयाम बदलता है: 4000x3000 की फ़ोटो को 1920x1440 करने पर एनकोड करने के लिए 75% कम पिक्सेल बचते हैं, जिससे किसी भी संपीड़न के चलने से पहले ही फ़ाइल-आकार घटता है। गुणवत्ता-कमी (स्लाइडर) नियंत्रित करती है कि JPEG या WebP एनकोडर अपने DCT-गुणांकों को कितनी आक्रामकता से पूर्णांकित करे, जो प्रति-पिक्सेल एनकोडेड डेटा को छोटा करता है। दोनों जुड़ते हैं: पहले रिसाइज़ करके कुल पिक्सेल-गिनती घटाएँ, फिर बचे हुए की गुणवत्ता कम करें। एक सामान्य «इसे वेब-अनुकूल बनाएँ» प्रवाह के लिए, Max Width 1920, गुणवत्ता 70 करें, और आउटपुट लगभग मूल आकार का 10-15% होता है।

क्या मैं अपने iPhone की HEIC छवियाँ संपीड़ित कर सकता हूँ?

HEIC डिकोडिंग के लिए ब्राउज़र-समर्थन सीमित है (Apple डिवाइसों पर Safari ऐसा करता है; Chrome और Firefox नहीं)। गैर-Apple ब्राउज़रों पर यह उपकरण HEIC फ़ाइलों को अस्वीकार करेगा। iPhone फ़ोटो के लिए प्रवाह यह है कि या तो iPhone की सेटिंग बदलें (कैमरा → Formats → अधिकांश संगत) ताकि सीधे JPEG सहेजे जाएँ, या एक बार Mac पर या किसी विशेष उपकरण से HEIC को JPEG में बदलें, फिर उन JPEG को इस संपीड़क से गुज़ारें। iCloud की «द्वारा साझा करें» शीट गैर-Apple प्राप्तकर्ताओं को साझा करते समय आम तौर पर स्वचालित रूप से JPEG में बदल देती है।

क्या कोई डेस्कटॉप या कमांड-लाइन समतुल्य उपलब्ध है?

कई। बैच-स्वचालन के लिए Node.js का sharp मानक सर्वर-साइड लाइब्रेरी है और लगभग समान आउटपुट देता है। ImageMagick (magick input.jpg -quality 70 output.jpg) और GraphicsMagick विशाल फ़ाइलों को संभालते हैं और किसी भी शेल से चलते हैं। jpegoptim और optipng विशिष्ट JPEG और PNG पुनः-एनकोडर हैं जो अक्सर सामान्य उपकरणों के मुक़ाबले कुछ अतिरिक्त प्रतिशत निकाल लेते हैं। इस उपकरण की तरह एक-बारगी इंटरैक्टिव काम पर अधिक नियंत्रण के साथ, Squoosh (Google Chrome Labs, यह भी पूरी तरह क्लाइंट-साइड) AVIF सहित व्यापक फ़ॉर्मेट-दायरे का समर्थन करता है।

संबंधित उपकरण