इमेज कंप्रेसर
JPG, PNG और WebP इमेज को अपने ब्राउज़र में कंप्रेस और रीसाइज़ करें। कोई इमेज छोड़ें, क्वालिटी समायोजित करें, चाहें तो फ़ॉर्मैट या डाइमेंशन बदलें, और छोटी फ़ाइल डाउनलोड करें — सब कुछ लोकल रूप से चलता है, इसलिए कुछ भी अपलोड नहीं होता। अंतिम समीक्षा 2026-06-19.
यहाँ कोई इमेज छोड़ें, या ब्राउज़ करें
JPG, PNG, WebP, GIF, BMP — लोकल रूप से प्रोसेस, कभी अपलोड नहीं।
यह कैसे काम करता है
यह टूल आपकी इमेज को एक HTML <canvas> पर बनाता है और ब्राउज़र के
मूल इमेज एन्कोडर से उसे दोबारा एन्कोड करता है। JPEG और WebP के लिए
क्वालिटी स्लाइडर तय करता है कि कितनी आक्रामकता से डिटेल हटाई जाए — कम क्वालिटी यानी छोटी फ़ाइल।
PNG लॉसलेस है, इसलिए स्लाइडर का उस पर कोई असर नहीं होता; PNG को आप रीसाइज़ करके या
उसे WebP में बदलकर छोटा करते हैं। चूँकि पूरी प्रक्रिया आपके ब्राउज़र में होती है, तस्वीर कभी कहीं नहीं
भेजी जाती, और री-एन्कोड करते समय EXIF/GPS मेटाडेटा भी हट जाता है।
JPEG बनाम WebP बनाम PNG
| फ़ॉर्मैट | कंप्रेशन | पारदर्शिता | किसके लिए सबसे अच्छा |
|---|---|---|---|
| JPEG | लॉसी | पारदर्शिता नहीं | फ़ोटो और जटिल इमेज के लिए। क्वालिटी स्लाइडर काम करता है — 70–80 आमतौर पर सबसे बढ़िया रहता है। |
| WebP | लॉसी या लॉसलेस | पारदर्शिता समर्थित | आधुनिक वेब इमेज। समान क्वालिटी पर आमतौर पर JPEG से 25–35% छोटी। क्वालिटी स्लाइडर काम करता है। |
| PNG | लॉसलेस | पारदर्शिता समर्थित | लोगो, आइकन, स्क्रीनशॉट और तीखे किनारों या पारदर्शिता वाली कोई भी चीज़। क्वालिटी स्लाइडर का कोई असर नहीं (PNG लॉसलेस है) — छोटा करने के लिए रीसाइज़ करें। |
छोटी इमेज के लिए सुझाव
- पहले रीसाइज़ करें। फ़ोन से सीधे ली गई फ़ोटो 4000 px चौड़ी हो सकती है; अधिकांश वेब और सोशल उपयोग को कभी 1600–2048 px से ज़्यादा की ज़रूरत नहीं होती। चौड़ाई आधी करने से फ़ाइल लगभग एक-चौथाई रह जाती है।
- क्वालिटी 70–85 फ़ोटो के लिए आमतौर पर मूल से अलग नहीं पहचानी जाती, जबकि साइज़ ख़ासा घट जाता है।
- वेब के लिए WebP चुनें — समान दृश्य क्वालिटी पर यह आमतौर पर JPEG से 25–35% छोटी होती है और हर मौजूदा ब्राउज़र इसे समर्थन करता है।
- ग्राफ़िक्स के लिए PNG रखें जिनमें तीखे किनारे, टेक्स्ट या पारदर्शिता हो; फ़ोटो को PNG से बाहर बदल लें, जिसके लिए PNG कभी बना ही नहीं था।
जानना ज़रूरी
- यदि "कंप्रेस्ड" फ़ाइल मूल से बड़ी निकले — जो पहले से ऑप्टिमाइज़ की गई JPEG को ऊँची क्वालिटी पर दोबारा सेव करने में आम है — तो अपनी मूल फ़ाइल रखें; टूल आपको बता देगा।
- एनिमेटेड GIF और एनिमेटेड WebP उनके पहले फ़्रेम तक समेट दिए जाते हैं (कैनवास एक ही फ़्रेम कैप्चर करता है)।
- आपकी मूल फ़ाइल कभी नहीं बदली जाती; आप हमेशा एक नई कॉपी डाउनलोड करते हैं।
लॉसी बनाम लॉसलेस: दो अलग सौदे
हर इमेज फ़ॉर्मैट दो में से एक वादा करता है। एक लॉसलेस फ़ॉर्मैट (PNG, GIF, या लॉसलेस मोड में WebP) यह गारंटी देता है कि आप जिस फ़ाइल को डिकोड करते हैं वह मूल के बिल्कुल समान है, पिक्सल दर पिक्सल — यह जगह सिर्फ़ मौजूदा पिक्सल को अधिक सघन रूप से वर्णित करके बचाता है। एक लॉसी फ़ॉर्मैट (JPEG, और अपने सामान्य मोड में WebP या AVIF) को वह जानकारी हटाने की छूट है जिसे आँख शायद ही चूकेगी, जो कुछ सटीकता की क़ीमत पर कहीं छोटी फ़ाइलें देता है। यही एक अंतर कंप्रेशन के व्यवहार के बारे में लगभग सब कुछ समझा देता है: क्वालिटी स्लाइडर का असर केवल किसी लॉसी फ़ॉर्मैट पर होता है, क्योंकि सिर्फ़ लॉसी फ़ॉर्मैट के पास ही हटाने की अनुमति वाली डिटेल होती है। किसी JPEG को क्वालिटी 60 पर चलाएँ तो कहीं छोटी फ़ाइल मिलती है; वही PNG के साथ करें तो स्लाइडर से कुछ नहीं होता, क्योंकि PNG के पास हटाने की अनुमति वाली कोई डिटेल नहीं होती।
यह सौदा रैखिक (linear) भी नहीं है। लॉसी फ़ॉर्मैट किसी फ़ोटो के फ़ाइल-साइज़ का पहला 60–70% ऐसे बदलावों के साथ हटा सकते हैं जो सामान्य देखने की दूरी पर सचमुच अदृश्य रहते हैं, फिर जैसे-जैसे आप उस बिंदु से आगे बढ़ते हैं जहाँ सिर्फ़ अर्थपूर्ण जानकारी बची रहती है, दिखाई देने वाली ख़राबी उभरने लगती है — मुलायम किनारे, धुँधला टेक्स्ट, ब्लॉकनुमा आसमान। कंप्रेशन की कला उस वक्र के मोड़ को खोजने में है, यही वजह है कि यह टूल एक तय सेटिंग लगाने के बजाय आपको पहले/बाद का साइज़ और एक लाइव पूर्वावलोकन दिखाता है।
एक JPEG के अंदर: क्वालिटी स्लाइडर असल में क्या बदलता है
JPEG (जिसका नाम Joint Photographic Experts Group से आया, जिसने इसे 1992 में मानकीकृत किया) इस बात के इर्द-गिर्द बना है कि मानव दृष्टि असल में कैसे काम करती है, और इसके चार चरणों को समझना क्वालिटी स्लाइडर को काफ़ी कम रहस्यमय बना देता है।
- रंग रूपांतरण। इमेज को RGB से YCbCr में बदला जाता है — एक चमक चैनल (Y, ल्यूमा) और दो रंग-अंतर चैनल (Cb और Cr, क्रोमा)। आँख रंग की तुलना में चमक के प्रति कहीं अधिक संवेदनशील है, इसलिए इन्हें अलग करने से एन्कोडर रंग को अधिक मोटे तौर पर संभाल सकता है।
- क्रोमा सबसैंपलिंग। अधिकांश JPEG दोनों रंग चैनलों को हर दिशा में आधे रिज़ॉल्यूशन पर
संग्रहीत करते हैं (जिसे
4:2:0कहते हैं), जो फ़ोटो पर लगभग बिना किसी दृश्य प्रभाव के रंग-डेटा तुरंत लगभग 50% घटा देता है — हालाँकि इसी कारण किसी भारी कंप्रेस्ड JPEG में बारीक लाल टेक्स्ट या संतृप्त किनारे रंगीन झालर जैसे दिख सकते हैं। - DCT। हर चैनल को 8×8 पिक्सल ब्लॉक में बाँटा जाता है, और एक डिस्क्रीट कोसाइन ट्रांसफ़ॉर्म हर ब्लॉक को पिक्सल से आवृत्ति गुणांकों (frequency coefficients) के एक समुच्चय में बदलता है — कुछ जो व्यापक टोन बताते हैं और कई जो बारीक डिटेल बताते हैं।
- क्वांटाइज़ेशन। यही एकमात्र अपरिवर्तनीय रूप से लॉसी चरण है। हर गुणांक को एक क्वांटाइज़ेशन तालिका के मान से भाग देकर पूर्णांकित किया जाता है, जो अधिकांश बारीक-डिटेल गुणांकों को शून्य कर देता है। क्वालिटी स्लाइडर बस उसी तालिका को स्केल करता है: कम क्वालिटी यानी मोटा भाग, अधिक शून्य, छोटी फ़ाइल — और अंततः वही दिखाई देने वाली 8×8 "ब्लॉकिंग" जो JPEG की पहचान वाली विकृति है।
तो जब आप इस टूल का क्वालिटी कंट्रोल नीचे खींचते हैं, तो आप ब्राउज़र के JPEG एन्कोडर से अधिक आक्रामकता से क्वांटाइज़ करने को कह रहे होते हैं। 70–85 के आसपास पूर्णांकन अधिकांश फ़ोटो के लिए बोध की सीमा से नीचे रहता है; लगभग 50 से नीचे ब्लॉक-संरचना और रंग-झालर दिखने लगती है। इसीलिए किसी पहले से कंप्रेस्ड JPEG को दोबारा कंप्रेस करना बेकार है: डिटेल पहली बार ही हट चुकी थी, इसलिए दूसरा दौर ज़्यादातर एक पहले से बिगड़ी इमेज में नई पूर्णांकन त्रुटि जोड़ता है। जब भी संभव हो, मूल से कंप्रेस करें।
WebP और AVIF: आधुनिक विकल्प
WebP, जिसे Google ने 2010 में जारी किया, VP8 वीडियो कोडेक की प्रेडिक्टिव कोडिंग को उधार लेता है: हर ब्लॉक को अलग-थलग कंप्रेस करने के बजाय, यह किसी ब्लॉक का उसके पड़ोसियों से अनुमान लगाता है और केवल अंतर संग्रहीत करता है। Google के अपने अध्ययन ने समान दृश्य क्वालिटी पर WebP लॉसी फ़ाइलों को JPEG से लगभग 25–34% छोटा, और WebP लॉसलेस फ़ाइलों को PNG से लगभग 26% छोटा मापा। यह पारदर्शिता और एनिमेशन का भी समर्थन करता है, जो JPEG कभी नहीं कर सका। हर मौजूदा ब्राउज़र इसे वर्षों से समर्थन करता आया है (Chrome 2010 से, Firefox 65, और Safari 14 में 2020 में), इसलिए अधिकांश वेब कार्य के लिए WebP ही समझदारी भरा डिफ़ॉल्ट है जो यह टूल देता है।
AVIF एक क़दम और आगे जाता है। रॉयल्टी-मुक्त AV1 वीडियो कोडेक पर बना, उसी HEIF कंटेनर के अंदर जिसे Apple iPhone फ़ोटो के लिए इस्तेमाल करता है, यह आमतौर पर JPEG से लगभग 50% छोटा तक पहुँचता है और फ़ाइल-साइज़ तथा रंग-गहराई दोनों में WebP को मात देता है। समर्थन अब व्यापक है (Chrome 85, Firefox 93, Safari 16), हालाँकि AVIF एन्कोडिंग धीमी है और AVIF लिखने के लिए ब्राउज़र-कैनवास समर्थन अब भी असमान है — यही कारण है कि यह टूल JPEG, WebP और PNG पर टिका है, वे तीन फ़ॉर्मैट जिन्हें हर ब्राउज़र भरोसेमंद रूप से पढ़ और दोबारा एन्कोड कर सकता है।
यहाँ PNG मुश्किल से क्यों सिकुड़ती है — और किसी को असल में कैसे कंप्रेस करें
PNG, जिसे W3C ने 1996 में GIF के पेटेंट-मुक्त विकल्प के रूप में अंतिम रूप दिया, डिज़ाइन से ही लॉसलेस है। यह दो चरणों में काम करती है: पिक्सल की हर पंक्ति को पहले फ़िल्टर किया जाता है (पाँच प्रेडिक्टर में से एक — None, Sub, Up, Average, या चतुर Paeth फ़िल्टर — हर पिक्सल को उसके पड़ोसियों से छोटे अंतर से बदल देता है), और फिर फ़िल्टर किए गए डेटा को DEFLATE से कंप्रेस किया जाता है, वही LZ77-प्लस-Huffman एल्गोरिदम जो ZIP फ़ाइलों के अंदर इस्तेमाल होता है। चूँकि यह कभी डिटेल नहीं हटाती, किसी PNG को उसी साइज़ पर ब्राउज़र कैनवास से दोबारा सेव करना उसे लगभग कभी छोटा नहीं बनाता — कैनवास का री-एन्कोडर उन सावधान प्रति-पंक्ति फ़िल्टर विकल्पों और पैलेट क्वांटाइज़ेशन की बराबरी नहीं कर सकता जिन्हें समर्पित PNG ऑप्टिमाइज़र (जैसे pngquant या OxiPNG) इस्तेमाल करते हैं।
तो यदि कोई PNG बहुत बड़ी है, तो आपके पास तीन अच्छे विकल्प हैं: उसे छोटा रीसाइज़ करें (कम पिक्सल ही एकमात्र चीज़ है जो हमेशा PNG को सिकोड़ती है); किसी फ़ोटो को PNG से बाहर बदलें JPEG या WebP में, क्योंकि PNG सपाट ग्राफ़िक्स, लोगो और स्क्रीनशॉट के लिए बनी थी, फ़ोटो के लिए नहीं; या PNG केवल वहीं रखें जहाँ आपको सचमुच लॉसलेस किनारे, तीखा टेक्स्ट, या पारदर्शिता चाहिए। किसी वेबपेज के स्क्रीनशॉट के लिए, WebP-लॉसलेस या रीसाइज़ की गई PNG आमतौर पर सही जवाब है; PNG के रूप में सेव की गई JPEG-जैसी फ़ोटो के लिए, फ़ॉर्मैट बदलने से फ़ाइल 80% या उससे ज़्यादा घट सकती है।
कंप्रेशन, पेज स्पीड और Core Web Vitals
इमेज आमतौर पर किसी वेब पेज का सबसे भारी हिस्सा होती हैं, इसलिए उन्हें कंप्रेस करना प्रदर्शन के लिए आप जो सबसे प्रभावी काम कर सकते हैं उनमें से एक है। एक छोटी इमेज तेज़ी से डाउनलोड होती है, जो सीधे Largest Contentful Paint (LCP) को बेहतर बनाती है — वह Core Web Vitals मीट्रिक जो मापती है कि मुख्य सामग्री कितनी जल्दी दिखती है, और जिसे Google एक रैंकिंग संकेत के रूप में इस्तेमाल करता है। मोबाइल कनेक्शन और सीमित डेटा प्लान पर 3 MB की फ़ोन फ़ोटो और 200 KB के वेब-तैयार संस्करण का फ़र्क़ एक ऐसे पेज और उस पेज के बीच का फ़र्क़ है जो तुरंत खुलता महसूस होता है बनाम जो दिखते-दिखते लोड होता है।
दो आदतें लाभ को कई गुना कर देती हैं। पहली, कंप्रेस करने से पहले रीसाइज़ करें: फ़ोन से सीधे ली गई फ़ोटो 4000 px चौड़ी हो सकती है, पर एक पूरी-चौड़ाई वाले वेब हीरो को शायद ही कभी 1600–2048 px से ज़्यादा की ज़रूरत होती है, और चौड़ाई आधी करने से पिक्सल-संख्या लगभग एक-चौथाई रह जाती है। दूसरी, इमेज को उसी साइज़ पर परोसें जिस पर वह असल में दिखती है — लेआउट में दिखने से ज़्यादा पिक्सल एन्कोड करना शुद्ध बर्बादी है। इस टूल का "अधिकतम चौड़ाई" कंट्रोल आपको दोनों काम एक ही दौर में करने देता है — मूल को डिकोड करना, उसे छोटा करना, और आपकी चुनी क्वालिटी पर दोबारा एन्कोड करना।
इसे आपके ब्राउज़र में करना क्यों मायने रखता है
अधिकांश "मुफ़्त इमेज कंप्रेसर" आपकी तस्वीर किसी सर्वर पर अपलोड करते हैं, उसे वहाँ प्रोसेस करते हैं, और
नतीजा वापस भेजते हैं — जिसका मतलब है कि आपकी फ़ोटो, जो भी उसमें हो, कुछ पल के लिए किसी और की मशीन पर रहती
है। यह टूल कभी ऐसा नहीं करता। यह इमेज को ब्राउज़र के अंतर्निर्मित createImageBitmap() से
डिकोड करता है, उसे एक ऑफ़-स्क्रीन <canvas> पर बनाता है, और ब्राउज़र के मूल
canvas.toBlob() एन्कोडर से दोबारा एन्कोड करता है, पूरी तरह आपके डिवाइस पर। कुछ भी अपलोड
नहीं होता, कुछ भी लॉग नहीं होता, और पेज एक बार लोड हो जाने के बाद यह ऑफ़लाइन भी काम करता रहता है।
कैनवास के काम करने के तरीक़े में एक प्राइवेसी बोनस भी छिपा है। किसी कैमरा फ़ोटो में एक EXIF मेटाडेटा ब्लॉक होता है — कैमरा मॉडल, ठीक तारीख़ और समय, और अक्सर वे GPS निर्देशांक जहाँ तस्वीर ली गई थी। कैनवास के ज़रिए दोबारा एन्कोड करने से एक साफ़ इमेज बनती है जिसमें कोई EXIF ब्लॉक बिल्कुल नहीं होता, इसलिए हर बार कंप्रेस करने पर वह डेटा अपने आप हट जाता है। जब आप कोई फ़ोटो सार्वजनिक रूप से पोस्ट करने वाले हों तो यह आदर्श है, और यदि आपको कभी वह मेटाडेटा वापस चाहिए तो अपनी मूल फ़ाइल सुरक्षित रखने की एक वजह भी।
आम कामों के लिए क्वालिटी सेटिंग चुनना
कोई एक "सही" क्वालिटी नहीं होती — यह इस पर निर्भर करता है कि इमेज कैसे देखी जाएगी। JPEG/WebP स्लाइडर के लिए शुरुआती बिंदु के रूप में:
| उपयोग | क्वालिटी | क्यों |
|---|---|---|
| हीरो / पूर्ण-स्क्रीन फ़ोटो | 80–85 | स्क्रीन पर बड़ी, इसलिए विकृतियाँ दिखेंगी; फिर भी अधिकांश साइज़ घटा देती है। |
| ब्लॉग बॉडी / थंबनेल | 70–80 | छोटा देखा जाता है; आँख अधिक क्षमा करती है, इसलिए आप ज़्यादा दबाव डाल सकते हैं। |
| सोशल मीडिया अपलोड | 75–82 | प्लेटफ़ॉर्म वैसे भी दोबारा कंप्रेस करता है — इसे पहले से बहुत ज़्यादा मत बिगाड़ें। |
| ईमेल अटैचमेंट | 65–75 | प्राथमिकता पिक्सल-पूर्णता से ज़्यादा एक छोटी, भेजने-योग्य फ़ाइल है। |
| बैकग्राउंड / सजावटी | 55–70 | दूसरी सामग्री के पीछे, इसलिए भारी कंप्रेशन अदृश्य रहता है। |
आप जो भी चुनें, किसी तय नियम के बजाय लाइव पूर्वावलोकन और पहले/बाद के आँकड़ों पर भरोसा करें — एक सपाट नीला आसमान और एक विस्तृत शहर-दृश्य समान क्वालिटी मान पर बहुत अलग व्यवहार करते हैं।
अक्सर पूछे जाने वाले सवाल
- क्या मेरी इमेज किसी सर्वर पर अपलोड होती है?
- नहीं। इमेज को अंतर्निर्मित Canvas API से पूरी तरह आपके ब्राउज़र में ही डिकोड और दोबारा एन्कोड किया जाता है — यह कभी आपके डिवाइस से बाहर नहीं जाती और न कभी लॉग या ट्रांसमिट होती है। पेज लोड हो जाने के बाद यह ऑफ़लाइन भी काम करती है, यही वजह है कि निजी फ़ोटो, स्क्रीनशॉट या स्कैन कंप्रेस करना सुरक्षित है।
- क्या कंप्रेस करने से इमेज की क्वालिटी घटती है?
- JPEG और WebP के लिए, हाँ — ये लॉसी हैं, इसलिए कम क्वालिटी सेटिंग फ़ाइल छोटी करने के लिए ज़्यादा डिटेल हटा देती है। फ़ोटो के लिए लगभग 70–85 आमतौर पर मूल से अलग नहीं पहचानी जाती। PNG लॉसलेस है, इसलिए इसे दोबारा एन्कोड करने से कभी क्वालिटी नहीं खोती; किसी PNG को छोटा करने के लिए उसके डाइमेंशन रीसाइज़ करें या उसे WebP में बदलें।
- वेब के लिए मुझे कौन-सा फ़ॉर्मैट चुनना चाहिए?
- WebP फ़ोटो और ग्राफ़िक्स दोनों के लिए सबसे छोटी फ़ाइलें देता है और हर मौजूदा ब्राउज़र इसे समर्थन करता है, इसलिए वेब के लिए यह सबसे अच्छा डिफ़ॉल्ट है। जब आपको अधिकतम संगतता चाहिए तब फ़ोटो के लिए JPEG इस्तेमाल करें, और PNG केवल तब जब आपको लॉसलेस क्वालिटी या पारदर्शिता चाहिए।
- मेरी कंप्रेस्ड PNG और छोटी क्यों नहीं हुई?
- PNG पहले से ही लॉसलेस है और कैनवास री-एन्कोडर वे पैलेट/क्वांटाइज़ेशन तरकीबें नहीं लगा सकता जो समर्पित PNG ऑप्टिमाइज़र इस्तेमाल करते हैं, इसलिए किसी PNG को उन्हीं डाइमेंशन पर दोबारा सेव करना शायद ही उसे सिकोड़ता है। किसी PNG को घटाने के लिए, "रीसाइज़" अधिकतम चौड़ाई कम करें, या उसे JPEG (यदि उसमें पारदर्शिता नहीं है) या WebP में बदलें — दोनों कहीं छोटी होंगी।
- क्या फ़ाइल-साइज़ या रिज़ॉल्यूशन की कोई सीमा है?
- कोई तय सीमा नहीं है, पर सब कुछ आपके ब्राउज़र टैब में होता है, इसलिए बहुत बड़ी इमेज (दसियों मेगापिक्सल) ज़्यादा मेमोरी लेती हैं और प्रोसेस होने में थोड़ा समय लगता है। यदि कोई बहुत बड़ी इमेज सुस्त लगे, तो "रीसाइज़" अधिकतम चौड़ाई सेट करें — अधिकांश वेब और सोशल उपयोग को कभी 1600–2048 px चौड़ाई से ज़्यादा की ज़रूरत नहीं होती।
- क्या यह मेरी फ़ोटो से EXIF / GPS मेटाडेटा हटाता है?
- हाँ। कैनवास के ज़रिए दोबारा एन्कोड करने से एक साफ़ इमेज बनती है जिसमें कोई EXIF ब्लॉक नहीं होता, इसलिए कैमरा मॉडल, तारीख़ और GPS स्थान अपने आप हट जाते हैं। फ़ोटो साझा करते समय यह एक प्राइवेसी लाभ है — हालाँकि इसका मतलब यह भी है कि यदि आप वह मेटाडेटा बनाए रखना चाहते हैं तो अपनी मूल फ़ाइल रखें।