मुफ़्त बैच इमेज कनवर्टर

कई छवियों को एक साथ PNG, JPG और WebP के बीच कनवर्ट करें। गुणवत्ता समायोजित करें, फ़ाइल आकार की तुलना करें और तुरंत सब कुछ डाउनलोड करें।

आपका डेटा कभी आपके डिवाइस से बाहर नहीं जाता
यहाँ छवियाँ छोड़ें या ब्राउज़ करने के लिए क्लिक करें (JPEG, PNG, WebP, GIF, BMP, TIFF)

प्रसंस्करण हो रहा है…

छवि प्रारूप रूपांतरण के बारे में

प्रत्येक छवि प्रारूप का अपना उपयोग है। PNG हानिरहित है, ग्राफ़िक्स के लिए आदर्श; JPG फ़ोटो के लिए उत्तम; WebP आधुनिक प्रारूप जो गुणवत्ता और आकार का संतुलन देता है।

JPEG (1992), फोटोग्राफ format

Joint Photographic Experts Group का गठन नवंबर 1986 में Parsippany, New Jersey में हुआ, जिसमें ISO TC97 SC2/WG8 और CCITT SGVIII समूह से सदस्य लिए गए। छह साल के समिति कार्य के बाद, CCITT Recommendation T.81 का text 18 सितंबर 1992 को अनुमोदित हुआ, उसी text को 1994 में ISO/IEC International Standard 10918-1 के रूप में प्रकाशित किया गया। यह दो-दस्तावेज़ प्रकाशन वह क्षण है जब JPEG दुनिया का फोटोग्राफ format बन गया। गणितीय कोर 8×8 pixel blocks पर लागू discrete cosine transform है: प्रत्येक block को cosine waves के योग में विघटित किया जाता है, उच्च-frequency components जिनके प्रति मानव दृष्टि सबसे कम संवेदनशील है, उन्हें कम-frequency वालों की तुलना में अधिक आक्रामक रूप से quantized किया जाता है जिन्हें आँख पहले नोटिस करती है। उपयोगकर्ता-मुख «quality» slider वास्तव में यही है, quantization table पर एक multiplier। उच्चतर quality का अर्थ है छोटे divisors, अधिक precision, बड़ी files। निम्न quality का अर्थ है quantization के बाद अधिक zeros, बेहतर entropy coding और दृश्यमान blocking और ringing artifacts की कीमत पर एक छोटी file। JPEG डिज़ाइन से ही lossy है: कोई quality setting नहीं है जिस पर एक JPEG round-trip गणितीय रूप से अपने input के समान हो। प्राकृतिक दृश्यों की photographs के लिए (चेहरे, परिदृश्य, भोजन, चिकनी gradients और निरंतर tone वाली कोई भी चीज़) यह अप्रासंगिक है; नुकसान मानव दृष्टि की संवेदनशीलता सीमा से नीचे रहता है और file उस आकार का एक अंश है जो एक lossless format produce करेगा। कठोर बढ़त, text, line art या बड़े flat color क्षेत्रों वाले graphics के लिए, JPEG गलत विकल्प है: वही DCT कठोर बढ़तों को ringing artifacts («mosquito noise») और 8×8 cells के बीच ब्लॉकी सीमाओं के साथ धुंधला कर देती है।

PNG (अक्टूबर 1996 / जनवरी 1997), lossless graphics format

PNG (Portable Network Graphics) was developed in 1994 by an informal group outside W3C as a deliberate response to two problems with the existing options: GIF's patent encumbrance (covered below) and TIFF's complexity. The specification was approved as a W3C Recommendation on 1 October 1996, and on 15 January 1997 it was released by the IETF as RFC 2083. A second edition incorporating errata became a W3C Recommendation on 10 November 2003; a third edition adding APNG, HDR support and Exif handling was published on 24 June 2025. PNG is lossless, every encoded byte is recoverable. Internally, a PNG file is a sequence of typed chunks (IHDR header, IDAT compressed data, IEND end-of-file marker, plus optional ancillary chunks for colour profile, transparency, gamma and metadata). Pixel data is preprocessed by one of five row filters (None, Sub, Up, Average, Paeth) chosen per scanline to maximise compressibility, then run through DEFLATE, the same algorithm used in zip files and gzip. PNG supports four colour modes: greyscale, greyscale with alpha, indexed colour (palette of up to 256 entries, what people call PNG-8), and truecolor RGB (PNG-24) with optional 8-bit alpha (PNG-32). The alpha channel supports 256 levels of partial transparency per pixel, which is what makes it possible to anti-alias the edges of icons against any background without the dreaded "white halo" PNG-8 indexed transparency used to produce. PNG was designed as a web format and an archival format simultaneously, and that dual role is why it remains the default for screenshots, logos, line art, charts, and any image where pixel-perfect reproduction matters more than file size.

GIF (15 जून 1987), animation का जीवित बचा और patent गाथा

CompuServe में engineering lead Steve Wilhite ने एक विशिष्ट समस्या को हल करने के लिए 15 जून 1987 को GIF पेश किया: CompuServe की online service के धीमे modems के माध्यम से रंगीन images को कैसे साझा किया जाए, बिना files को उपयोगकर्ता के मासिक भत्ते को निगलने दिए। उनकी टीम ने Lempel-Ziv-Welch (LZW) compression algorithm चुना और color palette को 256 entries पर capped किया। 1987 में CompuServe को जो पता नहीं था वह यह था कि LZW को Sperry Corporation (बाद में Unisys) द्वारा 1985 में patented किया गया था। 1994 के अंत में patent मुद्दा सार्वजनिक दृष्टि में उभरा। Unisys ने 1995 में घोषणा की कि वह algorithm का उपयोग करने वाले software पर (GIF, TIFF और PDF सहित) लगभग 0.45% से 0.65% revenue की दरों पर royalties लेगा। web के open-source community ने दो समानांतर कार्यों के साथ प्रतिक्रिया दी: «Burn All GIFs» अभियान और PNG का डिज़ाइन, स्पष्ट रूप से एक patent-free GIF प्रतिस्थापन के रूप में। Unisys US patent जून 2003 में समाप्त हुआ; अन्य अधिकार क्षेत्रों में संगत patents 2004 तक समाप्त हो गए। 2004 तक, GIF अपने इतिहास में पहली बार patent-unencumbered था। GIF एक feature की वजह से बच गया जो PNG (मूल रूप से) के पास नहीं था: animation। यह per-frame delay timings और एक transparent palette index के साथ frames के एक sequence का समर्थन करता है, जो इसे looping reaction images और web banners की lingua franca बनाता है। 256-color palette photos के लिए एक वास्तविक सीमा है, और 1-bit transparency एक रंगीन background पर overlay करते समय बदसूरत बढ़त बनाता है, लेकिन cartoon-style content के छोटे looping animations के लिए GIF अभी भी सार्वभौमिक समर्थन में जीतता है।

BMP (मई 1990) और TIFF (शरद 1986), विरासत रखवाले

BMP (Bitmap, जिसे Windows Device Independent Bitmap भी कहा जाता है) को Windows 3.0 में शामिल किया गया, जो 22 मई 1990 को जारी हुआ, जहाँ यह Windows graphical environment में bitmap storage के लिए मानक बन गया। यह अनिवार्य रूप से uncompressed है, कच्चा pixel array, वैकल्पिक रूप से 4-byte boundary पर row-aligned, सामने एक छोटा header के साथ। एक 1920×1080 24-bit BMP लगभग 6.2 MB है; वही image quality-85 JPEG के रूप में 200 KB हो सकती है। 2026 में BMP की भूमिका अनिवार्य रूप से एक विरासत interchange format के रूप में और वह format है जो Windows screenshots ऐतिहासिक रूप से उपयोग करते थे। TIFF (Tagged Image File Format) पहली बार Aldus Corporation द्वारा शरद 1986 (Revision 3.0) में प्रकाशित किया गया था; जून 1992 में Revision 6.0 ने CMYK और YCbCr color और JPEG-in-TIFF जोड़ा। Adobe ने 1994 में Aldus का अधिग्रहण किया और अब copyright रखता है। TIFF एकल encoding scheme के बजाय एक container format होने में अनूठा है, एक एकल TIFF file कई images रख सकती है (multi-page TIFF, fax और स्कैन की गई पुस्तक अध्यायों के लिए सामान्य), कई compression methods (none, LZW, ZIP, JPEG, fax के लिए CCITT Group 3/4) में से किसी का उपयोग करती है और अपनी tagged-field structure के माध्यम से अनिवार्य रूप से मनमाने metadata संग्रहीत करती है। यह लचीलापन TIFF को prepress workflows, scanning और document archival के लिए default बनाता है; इसे अनिवार्य रूप से कभी भी web images के लिए उपयोग नहीं किया जाता है। input list में इसकी उपस्थिति print-bound या scanned sources को web-friendly formats में convert करने वाले उपयोगकर्ताओं के लिए है।

WebP (30 सितंबर 2010), आधुनिक web format

Google ने 30 सितंबर 2010 को WebP की घोषणा web पर lossy compressed true-color graphics के लिए एक नए open format के रूप में की, जो तुलनीय quality पर JPEG से छोटी files उत्पन्न करता है। format VP8 video codec की keyframe encoding पर आधारित है, जिसे Google ने On2 Technologies की खरीद के साथ अधिग्रहित किया था। प्रारंभ में WebP केवल lossy था। 18 नवंबर 2011 को, Google ने lossless और lossy दोनों modes में एक lossless compression mode और transparency के लिए समर्थन की घोषणा की; libwebp 0.2.0 ने 16 अगस्त 2012 को एक स्थिर lossless implementation प्राप्त किया। Google के developer documentation के अनुसार: lossless WebP images PNG में समान images की तुलना में लगभग 26% छोटी हैं, और lossy WebP images समतुल्य SSIM quality पर तुलनीय JPEG की तुलना में 25-34% छोटी हैं। ये कमी कोई जादू नहीं हैं, वे एक मौलिक रूप से नए codec design (predictive intra-frame coding, modern arithmetic entropy coding, स्मार्ट color transformations) से आती हैं, जिसके खिलाफ JPEG और PNG 1990 के दशक की शुरुआत में डिज़ाइन किए गए थे। Browser support एक धीमा निर्माण था: Chrome 17 फरवरी 2012 (lossy), Chrome 23 नवंबर 2012 (lossless)। Apple ने एक दशक के बेहतर भाग के लिए धैर्य रखा और अंततः Safari 14 में WebP support जोड़ा, जो सितंबर 2020 में iOS 14 और macOS 11 Big Sur के साथ shipped हुआ। वह सितंबर 2020 तारीख वह क्षण है जब WebP iPhone उपयोगकर्ताओं के लिए JPEG fallback के बिना एक primary web format के रूप में व्यावहारिक रूप से उपयोग योग्य बन गया। आज coverage लगभग 97% global traffic है, WebP अब चेतावनियों के साथ एक «modern» format नहीं है, यह एक default है।

WebP से परे: AVIF (फरवरी 2019), HEIC (2017), JPEG XL (2018-)

AVIF v1.0.0 को 19 फरवरी 2019 को Alliance for Open Media (AOMedia, Google, Netflix, Microsoft, Mozilla, Cisco, Intel, Amazon, Apple का एक consortium) द्वारा जारी किया गया था। यह AV1 video codec का still-image profile है, HEIF container पर निर्मित, और वर्तमान में सबसे अच्छी compression करने वाला व्यापक रूप से तैनात image format है, समतुल्य visual quality पर, AVIF files सामान्यतः JPEG की तुलना में 50% छोटी और WebP की तुलना में 20-30% छोटी होती हैं। Browser support तीन तरंगों में आया: Chrome 85 (अगस्त 2020), Firefox 93 (अक्टूबर 2021), Safari iOS 16 के साथ (सितंबर 2022) और macOS Ventura (अक्टूबर 2022)। HEIC 2017 में iOS 11 के बाद से iPhone-default format है, HEVC-compressed images के साथ HEIF container, औपचारिक रूप से ISO/IEC 23008-12। Compression उत्कृष्ट है (सामान्यतः JPEG की तुलना में 50% छोटा) लेकिन HEVC patent-encumbered है, यही कारण है कि Chrome, Firefox और non-Apple Edge HEIC को natively decode करने से इनकार करते हैं। JPEG XL (ISO/IEC 18181, 2022) तकनीकी रूप से उत्कृष्ट niche format है, यह मौजूदा JPEGs को ~20% छोटा losslessly recompress कर सकता है, HDR, wide gamut, animation और progressive decoding का समर्थन करता है, और patent-free है। Chrome ने 31 अक्टूबर 2022 को अपना experimental flag गिरा दिया («Halloween decision»); Apple ने सितंबर 2023 में Safari 17 को macOS Sonoma, iOS 17 और visionOS में native JPEG XL के साथ shipped किया। Format Safari 17+ में natively समर्थित है, Firefox और Chrome 145 (फरवरी 2026) में एक flag के पीछे, लेकिन सामान्य traffic के लिए ship-by-default लंबित है। यह converter वर्तमान में AVIF, HEIC या JPEG XL उत्सर्जित नहीं करता, वे यहाँ सूचीबद्ध हैं ताकि आप तय कर सकें कि उन्हें upstream कैसे संभालें।

सही output format चुनना

ऊपर का format-by-format इतिहास एक भ्रमण है। व्यावहारिक प्रश्न छोटा है: एक विशेष image और एक विशेष उपयोग को देखते हुए, कौन सा output format सही है?

Quality slider वास्तव में क्या करता है

Quality slider 5 के steps में 10 से 100 तक चलता है। उस एकल संख्या के पीछे perceived quality और file size के बीच आश्चर्यजनक रूप से गैर-रैखिक संबंध है। JPEG के लिए, image-processing engineering में आम सहमति यह है कि quality 75-85 sweet spot है। quality 80 पर, file size सामान्य screen देखने की दूरी पर अगोचर visual अंतर के साथ uncompressed source से 70-90% गिरती है। quality 80 और 85 के बीच गिरावट तीव्र है: एक प्रतिनिधि test image quality 80 पर 3.7 MB से quality 85 पर 6 MB तक जा सकती है, phone या laptop screen पर कोई दृश्यमान सुधार के लिए लगभग दोगुना। Quality 75 वह जगह है जहाँ उच्च-frequency विवरण (text edges, बारीक textures) के करीबी निरीक्षण पर artifacts पता लगाने योग्य हो जाते हैं। Quality 90 और ऊपर archival JPEGs के लिए है जहाँ file size अप्रासंगिक है। 80 का default sweet spot के निचले छोर पर बैठता है, batch web optimization के लिए उपयुक्त, जहाँ लक्ष्य उतना कम data ship करना है जितना संभव हो जबकि स्वीकार्य दिखने वाली images रखी जाएँ। WebP के लिए, canvas API का toBlob('image/webp') default quality 0.80 है; quality 70 पर WebP आम तौर पर JPEG quality 80 के रूप में दृष्टिगत रूप से स्वच्छ होता है। PNG के लिए, «quality» एक misnomer है, PNG हमेशा pixel data पर lossless होता है। इस उपकरण में slider का कोई प्रभाव नहीं होता जब PNG को output format के रूप में चुना जाता है। batch processing के लिए महत्वपूर्ण सबक: एक एकल quality setting शायद ही कभी एक मिश्रित batch में हर image के लिए सही हो। एक ही camera में एक ही lighting में ली गई 50 photos का folder शायद सभी को बिना नुकसान के JPEG quality 80 पर save कर सकता है। screenshots, photos, line art और logos मिश्रित करने वाला folder नहीं, एक-button «JPG-80 में सब convert करें» screenshots को अपठनीय mosquito-noise में बदल देगा। जब content भिन्न हो तो input को अलग batches में विभाजित करें।

Lossy vs Lossless, सबसे महत्वपूर्ण भेद

एक lossless encoder गारंटी देता है कि decoded output encoded input के bit-समान है। PNG lossless है। WebP-lossless lossless है। TIFF (अपने lossless modes में) lossless है। Trade-off file size है: lossless encoders अगोचर perceptual मतभेदों का दोहन नहीं कर सकते और सब कुछ संरक्षित करना चाहिए। एक 1920×1080 photograph एक lossless PNG के रूप में 5 MB हो सकती है; उसी photo को JPEG-quality-85 के रूप में 200 KB है। PNG bit-perfect है; JPEG दृष्टिगत रूप से समकक्ष है। एक lossy encoder उस जानकारी को त्याग देता है जिसे मानव दृश्य प्रणाली द्वारा नोटिस किए जाने की सबसे कम संभावना है, उच्च-frequency विवरण, संतृप्त रंगों में बारीक chroma भिन्नता, हर gradient का चौथा महत्वपूर्ण आंकड़ा। JPEG, lossy WebP और lossy AVIF सभी ऐसा करते हैं। एक batch converter के लिए निहितार्थ ठोस हैं: lossless से lossless (PNG से PNG, या PNG से WebP-lossless) किसी भी संख्या के conversions में वास्तव में lossless है; एक ही quality पर lossy से lossy (JPEG-85 से JPEG-85) lossless नहीं है, हर re-encode एक और quantization step लागू करता है, 10 बार दोहराएँ और परिणाम दृष्टिगत रूप से degraded है; lossy से lossless (JPEG से PNG) मौजूदा artifacts को जगह में फ्रीज करता है लेकिन उन्हें फिर से degrade नहीं करता; lossless से lossy conversion के क्षण पर lossy compression पेश करता है और बाद में त्यागे गए विवरण को पुनर्प्राप्त करने का कोई तरीका नहीं है। उपयोगकर्ता अक्सर एक conversion को no-op होने की उम्मीद करते हुए फिर से चलाते हैं। lossless-to-lossless मामले के बाहर, यह नहीं है।

EXIF, IPTC, XMP, और यह उपकरण उन्हें क्यों हटाता है

cameras और phones से JPEG और HEIC files एक EXIF block ले जाती हैं, image header में embedded Exchangeable Image File Format metadata। EXIF में camera model, lens, exposure settings, date और time, software version, और सबसे महत्वपूर्ण रूप से जहाँ photo ली गई थी उसके GPS coordinates शामिल हैं (यदि capture समय पर location services on थीं)। IPTC metadata caption, byline, copyright और keywords जोड़ता है। XMP, मूल रूप से Adobe से, एक XML-आधारित superset है जो पुराने formats को subsume करता है और Lightroom और Photoshop उपयोग करते हैं। privacy निहितार्थ महत्वपूर्ण हैं। location सक्षम के साथ एक iPhone पर ली गई एक photo कुछ मीटर के भीतर सटीक GPS coordinates embed करती है। इसे एक forum पर, एक email attachment में, या एक व्यक्तिगत blog के माध्यम से साझा करना photographer के घर के पते, उनके बच्चे के स्कूल, उनके कार्यस्थल, उनके लंबी पैदल यात्रा मार्ग का खुलासा कर सकता है। प्रमुख social platforms (Facebook, Instagram, Twitter/X) image को अन्य उपयोगकर्ताओं को serve करने से पहले upload पर EXIF strip करते हैं, लेकिन वे मूल metadata खुद पढ़ते और संग्रहीत करते हैं। छोटे forums, WordPress blogs, Discord, email clients और प्रत्यक्ष file transfers EXIF को बरकरार छोड़ देते हैं। canvas API के माध्यम से re-encoding (वह engine जो यह उपकरण उपयोग करता है) default रूप से सभी EXIF, IPTC और XMP metadata को त्याग देता है। output embedded provenance के बिना एक स्वच्छ image है, एक privacy feature, और canvas pipeline का एक side effect (canvas केवल pixel data संग्रहीत करता है; इसके पास संरक्षित करने के लिए metadata का कोई concept नहीं है)। उपयोगकर्ता जो metadata को संरक्षित करना चाहते हैं (exposure data का archiving करने वाले photographers, content workflows जहाँ copyright file के साथ यात्रा करना चाहिए) एक अलग उपकरण की आवश्यकता है, आमतौर पर ImageMagick का convert या एक EXIF-aware library। यह converter दूसरे तरीके से काटता है: यह design से metadata-stripping है, जो बिल्कुल वही है जो एक privacy-conscious उपयोगकर्ता चाहता है जब वह images को एक forum पर भेजता है जहाँ वह नहीं चाहता कि उनके GPS coordinates अनुसरण करें।

पारदर्शी backgrounds, PNG-to-JPEG विकल्प

PNG प्रति-pixel alpha channel का समर्थन करता है: हर pixel में 0 (पूरी तरह पारदर्शी) से 255 (पूरी तरह अपारदर्शी) तक opacity होती है। JPEG के पास alpha channel नहीं है। transparency के साथ एक PNG को JPEG में convert करना एक विकल्प मजबूर करता है: पारदर्शी pixels को क्या बनना चाहिए? canvas API का default पारदर्शी काले के विरुद्ध composite करना है, इसलिए परिणामी JPEG पारदर्शी pixels को अपारदर्शी काले में हल करता है। एक पारदर्शी background पर एक logo PNG से JPEG में convert किया गया logo के चारों ओर काले कोनों के साथ बाहर आता है, व्यावहारिक रूप से कभी नहीं वही जो उपयोगकर्ता चाहता था। शमन image को ऊपर खींचने से पहले canvas को एक चयनित background color (सफेद आम default है) से भरना है। उपयोगकर्ता जिन्हें transparency संरक्षित करने की आवश्यकता है उन्हें output format के रूप में PNG या WebP चुनना चाहिए। WebP lossless और lossy दोनों modes में transparency का समर्थन करता है, जो इसे आधुनिक विकल्प बनाता है जब source में transparency है और destination को कुशल होने की आवश्यकता है, एक 50 KB का transparent-background PNG alpha channel को संरक्षित करते हुए एक 12 KB का transparent-background lossy WebP बन सकता है।

आपके browser में conversion कैसे चलता है

«सब कुछ आपके browser में चलता है» का दावा तीन Web Platform APIs पर टिका है जो हाल ही में एक batch image converter को एक विश्वसनीय client-side product बनाने के लिए पर्याप्त शक्तिशाली हो गए हैं। FileReader और Blob APIs: जब आप upload zone में files छोड़ते हैं, तो प्रत्येक File Blob की एक उपवर्ग है जो या तो readAsDataURL() (पुराना callback) या file.arrayBuffer() (Promise-आधारित) को expose करता है। विशेष रूप से images के लिए, सरल मार्ग URL.createObjectURL(file) के साथ एक Blob URL का निर्माण करना और इसे एक नए Image element को असाइन करना है, browser के built-in image decoder को JPEG, PNG, GIF, WebP और BMP को natively संभालने देना। Canvas API: एक बार Image load हो जाने पर, conversion दो-step नृत्य है, ctx.drawImage(img, 0, 0) के साथ draw करें, फिर canvas को canvas.toBlob(callback, type, quality) के साथ वापस पढ़ें। type पैरामीटर एक MIME string है ('image/png', 'image/jpeg', 'image/webp'); quality पैरामीटर lossy formats के लिए 0 और 1 के बीच एक संख्या है। OffscreenCanvas और Web Workers: बड़े batches के लिए, main thread पर सभी canvas कार्य करना UI को blocks करता है। आधुनिक समाधान OffscreenCanvas है, जो worker context में canvas operations को expose करता है और स्वयं postMessage के माध्यम से एक Web Worker को बिना copy किए transferable है। worker एक अलग thread में decode-rasterise-encode pipeline चलाता है, page को responsive रखता है। ये APIs एक साथ scrolling या button clicks को blocked किए बिना seconds में 50-file batch चलाते हैं। JSZip (एक pure-JavaScript MIT-licensed library) browser के save dialog के firing से पहले अंतिम ZIP packaging को पूरी तरह से memory में संभालता है। कोई upload नहीं, कोई server zip नहीं, disk पर कोई temporary file नहीं। एक दशक पहले एक batch image converter जो browser में चलता था एक जिज्ञासा होता। WebAssembly performance, OffscreenCanvas parallelism, और आधुनिक phone RAM (6-12 GB) और core counts (6-8 CPUs) ने उस चित्र को उलट दिया है। privacy तर्क मामले को बंद करता है: server-side converters आपकी images को एक तृतीय-पक्ष machine पर upload करने की आवश्यकता रखते हैं, और एक सावधानीपूर्ण deletion policy के साथ भी upload स्वयं एक network event है जो logged, intercepted या breached हो सकता है। एक browser-only converter कभी byte नहीं भेजता।

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

कौन से छवि फ़ॉर्मेट समर्थित हैं?

कन्वर्टर अधिकांश सामान्य फ़ॉर्मेट (JPG, PNG, GIF, WebP, BMP, TIFF) को प्रोसेस करता है और PNG, JPG या WebP में कनवर्ट करता है।

क्या मैं JPG और WebP के लिए गुणवत्ता समायोजित कर सकता हूँ?

हाँ। संपीड़न (0-100) समायोजित करने के लिए गुणवत्ता स्लाइडर का उपयोग करें। उच्च मान बेहतर गुणवत्ता देते हैं लेकिन बड़ी फ़ाइलें।

मैं कई फ़ाइलें कैसे डाउनलोड करूँ?

सभी कनवर्ट की गई छवियों को एकल ZIP संग्रह में जोड़ने के लिए «सभी को ZIP के रूप में डाउनलोड करें» चुनें, जिसे डाउनलोड और संग्रहीत करना आसान है।

प्रति batch सीमा 50 files क्यों है?

यह एक memory ceiling है। canvas के re-encode करने से पहले प्रत्येक image को कच्चे pixel data के रूप में RAM में decode किया जाना चाहिए। एक 12-megapixel iPhone photo लगभग 36 MB pixel data में decode होती है (12 million pixels × 3 bytes RGB, या 4 bytes RGBA)। एक साथ 50 1.8 GB working memory हैं। अधिकांश laptops इसे आराम से संभालते हैं; पुराने phones नहीं। 50-file cap devices में page को predictable रखता है। बड़े batches के लिए, उपकरण को rounds में चलाएँ, कहें, 50 files, download, clear, अन्य 50 छोड़ें।

क्या प्रति-file size सीमा है?

कोई कठोर cap नहीं, सीमा आपके device की उपलब्ध memory है। एक एकल 50 MP image लगभग 150 MB pixel data में decode होती है, जो एक desktop पर काम करता है लेकिन एक पुराने phone पर संघर्ष करेगा। थंब के नियम के रूप में, 10 MB से कम files अनिवार्य रूप से किसी भी device पर सुचारू रूप से convert होती हैं; 50 MB से अधिक files कम-end mobile पर धीमा हो जाएँगी या विफल हो जाएँगी। यदि एक conversion freeze होता है, page को refresh करें और file को छोटे batch में आज़माएँ।

क्या converter EXIF metadata strip करता है?

हाँ, design से। canvas re-encoding pipeline केवल pixel data संग्रहीत करता है, इसलिए EXIF, IPTC और XMP metadata blocks (camera model, exposure settings, GPS coordinates, copyright tags, edit history) round-trip से नहीं बचते। output embedded provenance के बिना एक स्वच्छ image है, जो एक privacy जीत है जब आप photos को forums या email contacts पर साझा कर रहे हैं जहाँ आप नहीं चाहते कि GPS coordinates अनुसरण करें। यदि आपको metadata संरक्षित करने की आवश्यकता है (exposure data archiving photographers, copyright tags की आवश्यकता वाले content workflows), यह गलत उपकरण है, ImageMagick का convert या एक dedicated EXIF-aware library उपयोग करें जो metadata को स्पष्ट रूप से संरक्षित करती है।

जब मैं PNG को JPG में convert करता हूँ तो पारदर्शी backgrounds का क्या होता है?

JPEG के पास alpha channel नहीं है, इसलिए source PNG में पारदर्शी pixels को JPEG output में किसी अपारदर्शी रंग बनना पड़ता है। canvas-default व्यवहार एक रंगीन background (आमतौर पर सफेद) के विरुद्ध composite करना है। एक पारदर्शी PNG background पर एक logo JPEG में convert किया गया transparency खो देगा और background fill उठाएगा। यदि transparency मायने रखती है, output format के रूप में PNG या WebP चुनें, दोनों alpha संरक्षित करते हैं। WebP-lossy PNG की तुलना में नाटकीय रूप से छोटे file आकारों पर transparency संरक्षित करता है और पारदर्शी web graphics के लिए आधुनिक विकल्प है।

क्या मेरी images कहीं upload की जाती हैं?

नहीं। हर step (file selection, decode, canvas re-encode, ZIP packaging, download) आपके browser में पूरी तरह से JavaScript के माध्यम से चलता है। कोई server-side processing नहीं है। आप convert करते समय अपने browser के DevTools Network tab खोलकर verify कर सकते हैं: image data ले जाने वाली कोई outbound requests नहीं हैं। page संवेदनशील screenshots, document scans, location metadata वाली व्यक्तिगत photos, या किसी अन्य चीज़ के लिए सुरक्षित है जिसे आप किसी अजनबी की hard drive पर copy नहीं देखना चाहते।

संबंधित टूल

PDF → HTML

PDF को तुरंत HTML में रूपांतरित करें।

Base64 एन्कोडर

Base64 में छवियाँ एन्कोड करें।

टेक्स्ट → CSV

CSV प्रारूप में डेटा रूपांतरित करें।