JPG, PNG, WebP, या AVIF अपलोड करें, क्वालिटी स्लाइडर एडजस्ट करें, और real time में नया साइज़ और savings देखें। JPG, WebP, AVIF, या PNG के रूप में export करें। बिना अपलोड, बिना account।
या यहां इमेज ड्रॉप करें
आपकी इमेज कभी भी आपके डिवाइस से बाहर नहीं जाती
RoundCut Compress Image आपकी JPG, PNG, WebP, या AVIF को पूरी तरह आपके ब्राउज़र में WebAssembly से re-encode करता है — फाइल कभी आपके device से बाहर नहीं जाती। क्वालिटी स्लाइडर से exact file size savings live देखें, JPG vs WebP vs AVIF एक नज़र में compare करें, फिर छोटी file डाउनलोड करें।
यह टूल आपकी पहले से मौजूद इमेज की एक छोटी copy बनाता है। Lossy formats (JPG, WebP, AVIF) को आपके चुने हुए क्वालिटी लेवल पर re-encode किया जाता है — क्वालिटी जितनी कम, file उतनी छोटी, जब तक visible artifacts नहीं आते। स्लाइडर drag करते समय आप live split-view preview और live file size counter देखते हैं, जिससे आप वह सबसे कम क्वालिटी चुन सकते हैं जो अभी भी सही दिखे। Output की dimensions बिल्कुल original जैसी रहती हैं; pixel size भी कम करना हो तो पहले Resize टूल इस्तेमाल करें।
जो file आप इस टूल में drop करते हैं वह कभी आपके ब्राउज़र से बाहर नहीं जाती। इस feature के लिए कोई server नहीं है, कोई analytics नहीं जो image pixels देखे, request chain में कोई third-party service नहीं। आप इसे खुद verify कर सकते हैं: DevTools खोलें, Network टैब पर जाएँ, image requests को filter करें, फिर टूल चलाएँ। Count शून्य रहेगा। इसका मतलब है यह एक scanned contract, confidential screenshot, बच्चों की फोटो, या NDA के तहत product shot — किसी भी ऐसी चीज़ के लिए safe है जहाँ server round-trip एक liability बनाए। एकमात्र network requests WebAssembly codec modules के one-time downloads हैं, जो static files हैं और आपकी image के बारे में कोई information नहीं रखते।
मुफ्त, बिना account, बिना signup, बिना watermark, और बिना per-image या per-day limit के। यह पहले encode के बाद offline काम करता है — WebAssembly modules आपके ब्राउज़र द्वारा cache हो जाते हैं, तो आप plane में या उस locked-down corporate network पर भी compress कर सकते हैं जहाँ server uploads blocked हों। यह क्या नहीं करता: resize नहीं करेगा — input dimensions = output dimensions (4000 px से 1200 px जाना हो तो पहले Resize टूल use करें)। EXIF, GPS, या camera metadata preserve नहीं करता — re-encoders by default इसे strip कर देते हैं, जो ज़्यादातर use cases में privacy के लिए अच्छा है। Batch नहीं: एक बार में एक इमेज। Target-size mode नहीं: स्लाइडर move करें और byte counter देखें — दो-तीन कोशिशों में कोई भी target size पा सकते हैं। GIF animation नहीं रहती: केवल पहला frame use होता है।
क्वालिटी स्लाइडर के नीचे आपको तीन cards दिखेंगे: JPG, WebP, और AVIF। सभी आपकी फोटो को आपके चुने quality पर encode करते हैं और finish होते ही resulting file size दिखाते हैं। जो सबसे छोटी file बनाता है उसे हरा «Smallest» badge मिलता है — उस card पर click करें, format set हो जाएगा, फिर download करें। यही TinyPNG जैसे auto-pickers से इस टूल का फर्क है: आप अपनी specific इमेज के, अपने specific quality level पर, commit करने से पहले actual numbers देखते हैं। यह guess नहीं करना पड़ता कि उस particular फोटो के लिए AVIF, WebP से छोटा होता या नहीं।
आपकी इमेज एक canvas में decode होती है, फिर चार professional codecs के WebAssembly builds से re-encode होती है: JPG के लिए MozJPEG, WebP के लिए libwebp, AVIF के लिए libavif, और PNG के लिए Oxipng — वही encoders जो Squoosh project use करता है। Encoding एक dedicated Web Worker में चलती है, इसलिए main thread कभी block नहीं होता और आप encode होते समय ब्राउज़र use करते रह सकते हैं। WebAssembly modules पहली बार हर format चुनने पर on demand load होते हैं; उसके बाद वे cache हो जाते हैं और हर अगला encode instant होता है — और offline भी काम करता है।
JPG (MozJPEG) उन फोटो के लिए सबसे safe choice है जो email, print, या किसी ऐसे workflow में जाएंगी जो newer formats support न करे — universal support, कोई transparency नहीं। WebP (libwebp) web के लिए best default है: same visual quality पर JPG से आमतौर पर 25–35% छोटा, और transparency support करता है। AVIF (libavif) compression को और आगे ले जाता है, JPG से अक्सर 40–60% छोटा, और Chrome, Firefox, Safari, और Edge में काम करता है; पहला encode WebAssembly module load होने तक कुछ seconds लेता है। PNG (Oxipng) lossless है — हर pixel preserve होता है; PNG के लिए क्वालिटी स्लाइडर hidden रहता है क्योंकि कुछ lose नहीं होता। Unoptimized PNG पर typical saving: 30–50%, ताज़े render किए exports पर 70% तक। Input के लिए टूल हर modern browser पर JPG, PNG, WebP, और AVIF accept करता है, plus GIF (केवल पहला frame) और HEIC (केवल Safari में)।
स्लाइडर lossy formats (JPG, WebP, AVIF) के लिए 1 से 100 तक चलता है। ज़्यादा = कम compression artifact और बड़ी file। कम = छोटी file, ज़्यादा visible degradation। 80 default है — यह Photoshop के 'high quality' JPEG tier से match करता है और ज़्यादातर professional workflows यही use करते हैं। 60 web-and-email के लिए solid default है जहाँ size ज़्यादा matter करता है। 50 से नीचे, smooth gradients और skin tones पर block artifacts आने लगते हैं। 30 से नीचे, output recognizable है लेकिन clearly compressed — केवल thumbnails के लिए उपयोगी। स्लाइडर के ऊपर size counter drag करते ही update होता है। यह re-encoded output का exact byte count दिखाता है — measured, estimated नहीं। जब re-encoded file आपकी uploaded file से बड़ी हो (जो already-compressed JPG पर quality 100 पर या किसी दूसरे टूल से पहले optimize हो चुके PNG पर होता है), saved value negative हो जाती है और card आपको सीधे बताता है: स्लाइडर कम करें या format बदलें।
हाँ। कोई account नहीं, कोई signup नहीं, कोई watermark नहीं, कोई trial period नहीं। यह पूरी तरह आपके ब्राउज़र में चलता है — हमारे लिए कोई server cost नहीं जो हम आप पर डालें।
नहीं। इमेज पूरी तरह आपके ब्राउज़र के अंदर decode और re-encode होती है। आप इसे DevTools के Network टैब में खुद confirm कर सकते हैं: टूल चलाते समय image requests filter करें और count शून्य रहेगा। इस feature को handle करने के लिए कोई server नहीं है — न हमारा, न किसी third party का।
हाँ। WebP सभी modern browsers पर supported input format है। आप एक WebP कंप्रेस करके उसे वापस WebP (छोटे) के रूप में export कर सकते हैं, या साथ ही उसे JPG या AVIF में convert भी कर सकते हैं।
हर modern browser पर JPG, PNG, WebP, और AVIF। GIF Chrome और Firefox में काम करता है लेकिन केवल पहला frame रहता है — animation preserve नहीं होती। iPhone से HEIC केवल Safari में काम करता है (Safari का native HEIC decoder है); Chrome या Firefox में पहले हमारे Convert टूल से HEIC को JPG में बदलें।
यह input पर depend करता है। Quality 80 पर एक typical unoptimized फोटो के लिए: WebP आमतौर पर JPG equivalent से 25–35% छोटा होता है; AVIF आमतौर पर JPG से 40–60% छोटा होता है। Oxipng से PNG 30–50% बचाता है unoptimized PNGs पर, ताज़े render किए ones पर 70% तक। Live size counter आपको download से पहले आपकी specific file का exact number दिखाता है।
अगर sure नहीं हैं तो 80 — यह default है और Photoshop के 'high quality' JPEG से match करता है। Web uploads के लिए जहाँ size ज़्यादा matter करे, 60 पर जाएँ। Thumbnails के लिए ही 40 तक जाएँ। अगर file को आगे edit करना हो और compression losses stack नहीं करना तो 90–100 रखें।
Quality 100 का मतलब no compression नहीं है — इसका मतलब है 'visible artifacts minimize करो।' अगर आपका input पहले से ही एक optimized JPG था, तो MozJPEG से quality 100 पर re-encode करने पर file बड़ी हो सकती है क्योंकि दोनों encoders ने अलग-अलग internal trade-offs किए। Fix: स्लाइडर कम करें जब तक size counter positive न हो जाए, या WebP या AVIF पर switch करें जो same visual quality पर छोटे compress होते हैं।
PNG output Oxipng से गुज़रता है, जो standard canvas export से बेहतर filter और deflate parameters चुनता है। Typical savings: unoptimized PNGs पर 30–50%, ताज़े render किए ones पर 70% तक। यह lossless रहता है — हर pixel input जैसा byte-identical। अगर आपको transparency की ज़रूरत नहीं है और dramatically छोटी file चाहिए, तो WebP quality 80 आमतौर पर किसी भी lossless PNG run को beat करता है — live format comparison से दोनों try करें।
नहीं। Width और height बिल्कुल वैसे ही रहते हैं। अगर आपको इमेज को भी downsize करना हो (जैसे 4000 px wide से 1200 px wide), तो पहले या बाद में Resize टूल use करें।
नहीं। Re-encoded file से EXIF, GPS, और camera metadata strip हो जाता है क्योंकि WebAssembly encoders source metadata carry नहीं करते। ज़्यादातर users के लिए यह privacy के लिए अच्छा है (file में GPS coordinates नहीं रहते), लेकिन अगर metadata preserve करना है तो यह सही टूल नहीं है।
अभी नहीं — एक बार में एक इमेज। एक-एक करके drop करें: JPG और WebP के लिए हर run एक second से कम लेता है, AVIF के पहले encode के लिए कुछ seconds लगते हैं।
Encoding: हाँ — हम एक WebAssembly libavif encoder ship करते हैं, इसलिए AVIF output हर modern browser में काम करता है चाहे browser का native AVIF encoder हो या नहीं। Output देखना: Chrome, Firefox, Safari, और Edge सभी AVIF support करते हैं। किसी specific recipient को file भेज रहे हैं तो एक बार test करें; WebP ज़्यादा safe universal choice है।
कोई hard cap नहीं है — यह आपके device की RAM पर depend करता है। एक modern laptop 50-megapixel फोटो एक-दो seconds में handle करता है। बहुत बड़ी files (~200 MB से ऊपर raw input) phones पर memory exhaust कर सकती हैं — ऐसी situation में पहले resize करें।
