क्रॉप

इमेज क्रॉप करें गोल क्रॉप करें

ऑप्टिमाइज़

इमेज कंप्रेस करें इमेज अपस्केल करें बैकग्राउंड हटाएं

बदलाव

इमेज रीसाइज़ करें

कन्वर्ट

अन्य

JPG को PDF में बदलें

आपकी फ़ाइलें लोड हो रही हैं…

WebP को AVIF में बदलें, छोटी फाइल और alpha बरकरार

WebP को AVIF में बदलें और ऐसी फोटो पाएं जो transparency बनाए रखते हुए 20 से 30 प्रतिशत छोटी रहती हैं।

या यहां इमेज ड्रॉप करें

त्वरित उत्तर

कुछ क्लिक में WebP को AVIF में बदलें। चूँकि AVIF बनाने में सबसे भारी फॉर्मेट है, सबसे अच्छे नतीजे के लिए भारी काम हमारा सर्वर करता है, इसलिए AVIF में बदलने पर इमेज हमारे सर्वर तक जा सकती है। जब आप एक साथ कई फाइलें बदलते हैं, तो सर्वर हमेशा पूरे बैच को संभालता है और डाउनलोड लिंक लगभग 2 घंटे में मिट जाता है। दोनों फॉर्मेट गुणवत्ता हानि वाला हैं, इसलिए यह दूसरा गुणवत्ता हानि वाला पास है, यानी WebP बनाते समय पहले से दबाई गई कलर डिटेल फिर से दबती है। फोटो पर quality 85 का नतीजा देखने में लगभग बिना नुकसान के होता है, करीब, और आउटपुट आम तौर पर सोर्स WebP से 20 से 30 प्रतिशत छोटा रहता है। अगर आपकी WebP का बैकग्राउंड पारदर्शी है, तो पारदर्शिता परत बरकरार रहता है। ईमानदारी से, कमज़ोरी रफ्तार है। 20 लाख पिक्सेल की फोटो एक सेकंड से कम लेती है, 80 लाख पिक्सेल कुछ सेकंड, और बड़ी इमेज ज़्यादा। सेशन का पहला कन्वर्ज़न छोटा सा वार्म-अप ले सकता है।

WebP को AVIF में कैसे बदलें

WebP को AVIF में कैसे बदलें

WebP को अपलोड क्षेत्र पर छोड़ें या उस पर क्लिक करके फाइल चुनें। फाइल पहुँचते ही कन्वर्ज़न शुरू हो जाता है, अलग से कोई बटन नहीं। चूँकि AVIF बनाने में सबसे भारी फॉर्मेट है, एक इमेज सबसे अच्छे नतीजे के लिए हमारे सर्वर पर भेजी जाती है, और AVIF डाउनलोड के लिए तैयार लौटता है। छोटी इमेज एक सेकंड से बहुत कम में बदल जाती है, 20 लाख पिक्सेल की फोटो करीब एक सेकंड में, 80 लाख पिक्सेल कुछ सेकंड में। AVIF तैयार होने पर डाउनलोड पर क्लिक करें ताकि वही मूल नाम और नया.avif एक्सटेंशन मिले। आँकड़ों की पंक्ति दोनों आकार दिखाती है, और डाउनलोड लिंक लगभग 2 घंटे में मिट जाता है।

AVIF, WebP से कितनी छोटी होती है

AVIF, WebP से कितनी छोटी होती है

AVIF, एक आधुनिक प्रारूप कोडेक पर बनी है और तथा तुलनाओं के अनुसार फोटो टेस्ट सेट पर समान देखने वाली quality पर WebP से करीब 20 से 30 प्रतिशत छोटी फाइल तक पहुंचती है। सपाट रंग या तीखे किनारों वाले सादे ग्राफिक्स पर अंतर घट जाता है, और WebP बराबर या आगे आ सकती है। सबसे बड़ी जीत फोटो पर है, वही इमेज जो आज ज्यादातर साइटों का वजन सबसे ज्यादा बढ़ाती हैं। की WebP बराबर देखने वाली quality पर AVIF के रूप में 22 से तक आ सकती है। बहुत ज्यादा दबाई गई WebP स्रोतों पर बचत और कम होती है। AVIF का ब्राउज़र सपोर्ट अब दुनिया भर में 93 प्रतिशत पार कर गया है, इसलिए आधुनिक दर्शकों के लिए fallback की जरूरत एक छोटी संख्या तक सिमट गई है।

क्या WebP से AVIF transparency बनाए रखता है

क्या WebP से AVIF transparency बनाए रखता है

हां। WebP एक पारदर्शिता परत रखती है और AVIF भी, और कन्वर्ज़न इसे बिना बदले पार ले जाता है। transparent बैकग्राउंड वाली WebP उसी transparent बैकग्राउंड वाली AVIF में बदल जाती है, कोई सफेद भराव नहीं, कोई रंग बदलाव नहीं, किनारों पर कोई halo नहीं, -alpha वाली कोई हैरानी नहीं। यह JPG में बदलने का उल्टा है, जहां alpha मिट जाता है क्योंकि JPG में transparency नहीं होती। अगर आपकी WebP में कोई कट-आउट लोगो, UI स्प्राइट, या transparent कैनवस पर स्टिकर है, तो AVIF एक सुरक्षित मंजिल है और आपको इमेज को पहले flatten करने की जरूरत नहीं। Alpha plane को कलर डेटा के साथ quality 85 पर सेव किया जाता है और यह नरम किनारों के साथ आउटपुट में पहुंचता है।

Quality और कन्वर्ज़न की गति

Quality और कन्वर्ज़न की गति

दोनों फॉर्मेट गुणवत्ता हानि वाला हैं, और यह जोड़ी quality 85 पर चलती है। उस सेटिंग पर फोटो करीब नापती हैं, नैचुरल इमेज के लिए देखने में लगभग गुणवत्ता हानि रहित। तीखे किनारों या सपाट रंग वाले ग्राफिक्स हल्के artifacts दिखा सकते हैं। चूंकि स्रोत पहले से एक गुणवत्ता हानि वाला WebP है, यह दूसरा गुणवत्ता हानि वाला पास है, यानी WebP ने पहले जो जानकारी छोड़ दी वह वापस नहीं आ सकती। AVIF की कम्प्रेशन क्षमता का सौदा गति है। Chrome डेस्कटॉप पर 2 मेगापिक्सल की फोटो एक सेकंड से कम में, 8 मेगापिक्सल की करीब 3 सेकंड में, और 24 मेगापिक्सल की 10 से 30 सेकंड में पूरी होती है। Firefox करीब चार गुना धीमा चलता है, और फोन डेस्कटॉप Chrome से 3 से 5 गुना धीमा है। पहला रन एक बार की warm-up भी लेता है।

डिलीवरी के लिए AVIF का ब्राउज़र सपोर्ट

डिलीवरी के लिए AVIF का ब्राउज़र सपोर्ट

AVIF अब दुनिया भर के 93 प्रतिशत से ज्यादा ब्राउज़रों तक पहुंचती है, Chrome 85 और बाद के, Firefox 93 और बाद के, Safari 16.4 और बाद के, तथा Edge 121 और बाद के सभी इसे अपने आप दिखाते हैं। Internet Explorer, Opera Mini, और 2022 से पहले के Safari नहीं दिखाते। डिलीवरी के लिए इसका व्यावहारिक मतलब यह है कि WebP fallback के साथ AVIF देने वाला HTML picture एलिमेंट लगभग सारे आधुनिक ट्रैफिक को कवर करता है। जहां बाकी कुछ प्रतिशत से मेल जरूरी हो, वहां WebP fallback बनाए रखें। जहां आधुनिक ब्राउज़र दर्शकों का भरोसा हो, वहां अकेली AVIF चल सकती है। बैंडविड्थ की बचत के कारण 2026 में परफॉर्मेंस पर ध्यान देने वाले डेवलपरों के बीच WebP fallback के साथ पहले AVIF देना सबसे आम तरीका है।

आपकी फाइल कहाँ प्रोसेस होती है

आपकी फाइल कहाँ प्रोसेस होती है

AVIF बनाने में सबसे माँग वाला फॉर्मेट है, इसलिए यह जोड़ी सबसे अच्छा नतीजा देने के लिए हमारे सर्वर का इस्तेमाल करती है, यानी AVIF में बदलने पर आपकी WebP वहाँ भेजी जा सकती है। काम होता है, AVIF लौटता है, और डाउनलोड लिंक लगभग 2 घंटे में मिट जाता है। जब आप एक साथ कई फाइलें बदलते हैं, तो सर्वर हमेशा बैच संभालता है और नतीजों को एक पैकेज में जोड़ता है, फिर वही लगभग 2 घंटे की खिड़की। अगर सर्वर कभी उपलब्ध न हो, तो पेज इसके बजाय एक इमेज ब्राउज़र में बनाता है और उस एक फाइल को डिवाइस पर रखता है। हम न खाता, न प्रोफाइल, न आपकी इमेज की कॉपी उस छोटी प्रोसेसिंग खिड़की से आगे रखते हैं। ईमानदार सार: एक AVIF क्वालिटी के लिए हमारे सर्वर पर बन सकता है, बैच हमेशा ऐसे ही बनता है, और उसके बाद आपका कुछ नहीं रहता।

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

  1. अपनी WebP छोड़ें

    WebP को अपलोड एरिया पर खींचें, या फाइल पिकर खोलकर अपने डिवाइस से एक चुनने के लिए उस पर क्लिक करें।

  2. बदलने दें

    AVIF बनाने में सबसे भारी फॉर्मेट है, इसलिए इमेज सबसे अच्छे नतीजे के लिए हमारे सर्वर पर भेजी जाती है। डाउनलोड लगभग 2 घंटे में मिट जाता है।

  3. साइज देखें

    जब AVIF तैयार हो जाए, स्टैट्स लाइन WebP स्रोत साइज और AVIF आउटपुट साइज दिखाती है। फोटो पर 20 से 30 प्रतिशत की कमी सामान्य है।

  4. AVIF डाउनलोड करें

    फाइल को उसी बेस नाम और नई.avif एक्सटेंशन के साथ अपने डिवाइस पर save करें के लिए Download पर क्लिक करें।

मिलती-जुलती कन्वर्ज़न

जब आपको ज्यादा compatibility चाहिए तो WebP पर लौटें, या और बड़ी बचत के लिए गुणवत्ता हानि रहित PNG से शुरू करें।

AVIF से WebP PNG से AVIF सभी कनवर्टर

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

क्या AVIF, WebP से बेहतर है

आधुनिक ब्राउज़र दर्शकों को दी जाने वाली फोटो के लिए AVIF कम्प्रेशन में जीतती है, फोटो टेस्ट सेट पर माप के अनुसार समान देखने वाली quality पर आमतौर पर 20 से 30 प्रतिशत छोटी फाइलें। सपाट रंग और तीखे किनारों वाले ग्राफिक्स पर WebP टक्कर देती है और कभी-कभी छोटी फाइल बना सकती है। दोनों alpha और एनिमेशन रखते हैं। अगर आपके दर्शक आधुनिक ब्राउज़र इस्तेमाल करते हैं, इस समय दुनिया भर में करीब 93 प्रतिशत यूज़र, तो AVIF बेहतर डिफॉल्ट है। वरना WebP को fallback के रूप में रखें।

क्या WebP को AVIF में बदलते समय quality घटेगी

हां, थोड़ी जनरेशन लॉस अनिवार्य है। दोनों फॉर्मेट गुणवत्ता हानि वाला हैं, इसलिए गुणवत्ता हानि वाला WebP को AVIF quality 85 पर दोबारा सेव करना एक दूसरा कम्प्रेशन पास जोड़ता है। फोटो पर नतीजा देखने में लगभग गुणवत्ता हानि रहित होता है, करीब नापते हुए। तीखे किनारों या सपाट रंग वाले ग्राफिक्स पर हल्के artifacts की उम्मीद करें। गुणवत्ता हानि वाला WebP स्रोत से पूरी तरह गुणवत्ता हानि रहित AVIF संभव नहीं, क्योंकि WebP ने जो जानकारी छोड़ी वह इस कन्वर्ज़न के शुरू होने से पहले ही जा चुकी है।

क्या AVIF, WebP की तरह transparency रखती है

हां। WebP और AVIF दोनों पारदर्शिता परत रखते हैं, और कन्वर्ज़न transparency को ठीक वैसे ही पार ले जाता है, बिना सफेद भराव, बिना रंग बदलाव, और बिना किनारों के halo के। यह JPG में बदलने से अलग है, जहां alpha हमेशा के लिए मिट जाता है क्योंकि JPG में transparency नहीं होती। अगर आपकी WebP का बैकग्राउंड transparent है, तो आपकी AVIF का भी होगा, उन्हीं नरम किनारों और आधे transparent पिक्सल के साथ। कन्वर्ट करने से पहले किसी मैन्युअल flatten की जरूरत नहीं।

WebP से AVIF कन्वर्ज़न में कितना समय लगता है

सेशन का पहला रन तैयारी को करीब एक सेकंड में लोड करता है। उसके बाद, 2 मेगापिक्सल की इमेज Chrome पर एक सेकंड से कम में, 8 मेगापिक्सल करीब 3 सेकंड में, और 24 मेगापिक्सल 10 से 30 सेकंड ले सकती है। AVIF पर Firefox, Chrome से करीब चार गुना धीमा चलता है, इसलिए Firefox पर बड़ी इमेज आधे मिनट तक अटक सकती है। फोन डेस्कटॉप से 3 से 5 गुना धीमा है। बड़ी फाइलों या Firefox यूज़र के लिए डेस्कटॉप पर Chrome सबसे तेज़ रास्ता है।

AVIF की सेविंग, WebP से धीमी क्यों है

AVIF, एक आधुनिक प्रारूप कोडेक पर बनी है, जो WebP के आधारित एल्गोरिदम से कहीं ज्यादा जटिल prediction और लगाती है। एक आधुनिक प्रारूप को कम्प्रेशन को अधिकतम करने के लिए बनाया गया था, बेहतरीन आउटपुट के बदले धीमी सेविंग स्वीकार करते हुए। AVIF का डिकोडिंग हर आधुनिक ब्राउज़र में तेज़ है क्योंकि हार्डवेयर डिकोड आम है। पर सेव करना भारी काम है, और बड़ी फोटो के लिए गणना सचमुच भारी होती है, इसीलिए यह तुरंत नहीं होती।

WebP को AVIF में कब बदलना चाहिए

जब आप डिलीवरी का माहौल पूरी तरह अपने हाथ में रखें और आपके दर्शक आधुनिक ब्राउज़र इस्तेमाल करें, तो फोटो और फोटो जैसी सामग्री के लिए WebP से AVIF में जाना सही है, जहां 20 से 30 प्रतिशत की साइज बचत तेज़ LCP स्कोर में बदलती है। यह छोटे आइकन या सादे ग्राफिक्स के लिए कम उपयोगी है जहां WebP पहले से छोटी है, ज्यादा ट्रैफिक वाले पेजों के लिए जहां सेविंग का समय एक पाइपलाइन को रोक दे, या जब मंजिल वाला सिस्टम खासतौर पर WebP मांगे।

विवरण

अच्छे नतीजे के पीछे शिल्प, प्रारूपों और छोटे निर्णयों पर टीम के नोट्स।

फोटो पर AVIF, WebP से क्यों जीतती है
WebP पर AVIF की कम्प्रेशन बढ़त नीचे के कोडेक से आती है। WebP, इंट्रा-फ्रेम इंजन इस्तेमाल करती है, जो वीडियो के लिए बना था पर 2010 से स्टिल के लिए इस्तेमाल होता है। एक आधुनिक प्रारूप, AVIF के पीछे का कोडेक, और की सीमाओं पर सीधे केंद्रित सालों के शोध के बाद 2018 में आया। एक आधुनिक प्रारूप ज्यादा आक्रामक, 4 बाय 4 पिक्सल तक की बारीक, और एक ज्यादा असरदार लगाती है। व्यावहारिक नतीजा, बड़े फोटो टेस्ट सेट पर विश्लेषण से पुष्ट, यह है कि फोटो पर समान देखने वाली quality पर AVIF आमतौर पर WebP से 20 से 30 प्रतिशत छोटी होती है। सपाट रंग और तीखे किनारों वाले कंप्यूटर-जनित ग्राफिक्स पर अंतर घटता है, क्योंकि WebP का सरल एल्गोरिदम उन पैटर्नों को कुशलता से संभालता है। जिस भी पेज के सबसे भारी एसेट फोटो हों, वहां AVIF अपग्रेड का मापने लायक बैंडविड्थ असर है।
व्यवहार में दूसरा गुणवत्ता हानि वाला पास
जब आप WebP को AVIF में बदलते हैं, स्रोत और आउटपुट दोनों गुणवत्ता हानि वाला हैं। WebP को पहली बार बनाते समय WebP ने पहले ही तय कर लिया था कि कौन सी कलर जानकारी छोड़नी है, और वे फैसले स्थायी हैं, AVIF में बदलना उनमें से कुछ भी वापस नहीं ला सकता। फिर AVIF को मिले पिक्सल डेटा पर quality 85 पर अपने फैसले लेने होते हैं। फोटो पर दो गुणवत्ता हानि वाला पास का संयुक्त असर आम डिस्प्ले साइज पर अब भी देखने में लगभग गुणवत्ता हानि रहित रहता है, असली फोटो सामग्री पर करीब। अपनी WebP सेविंग से पहले ही घटी हुई ग्राफिक्स पर दूसरा पास दिखने वाले artifacts को और बढ़ा सकता है। व्यावहारिक नियम, अगर स्रोत WebP जिस साइज पर दिखाना है उस पर साफ दिखती है, तो AVIF भी साफ दिखेगी। अगर WebP पहले से कम्प्रेशन नॉइज़ दिखाती है, तो भेजने से पहले AVIF को ध्यान से जांचें।
पारदर्शिता परत कैसे पार होता है
WebP और AVIF दोनों transparency को कलर डेटा के साथ एक अलग alpha plane में रखते हैं। कन्वर्ज़न WebP का पारदर्शिता परत पढ़ता है, उसे पूरी transparency पर जोड़ता है, फिर AVIF को सौंपता है, जो एक आधुनिक प्रारूप इंट्रा-फ्रेम coding से quality 85 पर अपना alpha ट्रैक लिखती है। नरम transparency gradient, मुलायम किनारे, और आधे transparent हिस्से सभी इस सफर को पार कर जाते हैं। AVIF का alpha plane खुद quality 85 पर गुणवत्ता हानि वाला है, जो बहुत ज्यादा ज़ूम पर तीखे किनारों पर मुश्किल से दिखने वाली फ्रिंजिंग ला सकती है। वेब पर आम देखने वाले साइज पर स्रोत से अंतर नहीं दिखता। छोटे आइकन पर पिक्सल-परफेक्ट काम के लिए जहां alpha किनारा सटीक होना चाहिए, WebP स्रोत रखें और भेजने से पहले आउटपुट को पूरे ज़ूम पर जांचें।
ब्राउज़रों और डिवाइसों पर सेविंग का समय
AVIF की तैयारी हर ब्राउज़र सेशन में एक बार होती है, पहले कन्वर्ज़न में करीब एक सेकंड जोड़ते हुए। उसके बाद Chromium सबसे अच्छी थ्रूपुट देती है, 0.12 मेगापिक्सल थंबनेल के लिए करीब 40 मिलीसेकंड, 1 मेगापिक्सल फोटो के लिए 250 मिलीसेकंड, 4K फोटो के लिए 2.8 सेकंड, और सबसे बुरी स्थिति में पूरे 48 मेगापिक्सल इमेज के लिए 25 सेकंड। Firefox उल्लेखनीय अपवाद है, उसी तैयारी को करीब चार गुना धीमा चलाते हुए, जो 4K केस को करीब 31 सेकंड और बड़ी फाइलों को दो मिनट के पार ले जाता है। WebKit दोनों के बीच बैठती है, Chromium के करीब। मोबाइल हार्डवेयर हर इंजन पर डेस्कटॉप से 3 से 5 गुना धीमा चलता है। रोज़मर्रा की फाइल-दर-फाइल कन्वर्ज़न के लिए, लैपटॉप या डेस्कटॉप पर Chrome व्यावहारिक औज़ार है। बड़ी इमेज वाले Firefox यूज़र के लिए साफ सलाह है कि ब्राउज़र बदलें या WebP रखें।
Core Web Vitals और AVIF अपग्रेड
फोटो देने वाले पेज हर लोड होने वाली इमेज के लिए बैंडविड्थ की कीमत चुकाते हैं। अगर वे इमेज इस समय WebP हैं, तो उन्हें AVIF में बदलना फोटो पर प्रति-इमेज ट्रांसफर को करीब 20 से 30 प्रतिशत घटाता है। WebP हीरो इमेज वाले पेज पर AVIF उसे करीब 140 से तक लाती है। बारह WebP थंबनेल वाले प्रोडक्ट ग्रिड पर AVIF कुल पेज वजन में करीब 70 से बचाती है। जब LCP एलिमेंट कोई इमेज हो, ये बचत सीधे Largest Contentful Paint को प्रभावित करती हैं। AVIF के लिए करीब 94 प्रतिशत वैश्विक ब्राउज़र सपोर्ट पर, WebP fallback के साथ पहले AVIF देने वाला picture एलिमेंट लगभग सारे ट्रैफिक को कवर करता है। markup की कीमत हर इमेज कंपोनेंट पर एक बार चुकती है, और बैंडविड्थ की बचत उसके बाद हर पेज लोड पर दोहराई जाती है।
AVIF कन्वर्ज़न सर्वर पर क्यों टिकता है
AVIF, एक आधुनिक प्रारूप कोडेक पर बना है, वही परिवार जो आधुनिक वीडियो इस्तेमाल करता है, और छोटी फाइलों के बदले इसे जानबूझकर बनाने में भारी रखा गया है। यह काम अच्छे से करना, खासकर बड़ी फोटो पर, फोन के ब्राउज़र की तुलना में असली सर्वर पर कहीं तेज़ और भरोसेमंद है, इसलिए यह जोड़ी सबसे अच्छा संभव AVIF बनाने के लिए इमेज हमारे सर्वर पर भेजती है। फाइल प्रोसेस होती है और नतीजा आपको लौटता है, और डाउनलोड लगभग 2 घंटे में हटा दिया जाता है, बिना खाते और बिना लंबे भंडारण के। एक साथ कई इमेज बदलना हमेशा सर्वर पर चलता है, जो तैयार सेट को एक डाउनलोड में जोड़ता है, उसी छोटी अवधि में मिटा देता है। अगर हमारे सर्वर तक न पहुँचा जा सके, तो एक कन्वर्ज़न इसके बजाय ब्राउज़र में बनता है, वह फाइल स्थानीय रहती है, सुविधा के लिए धीमी बनावट को स्वीकार करते हुए। सौदा साफ है: सर्वर उस फॉर्मेट पर क्वालिटी और रफ्तार खरीदता है जिसे इसकी सबसे ज़्यादा ज़रूरत है, और आपकी फाइल कभी भी कन्वर्ज़न की छोटी खिड़की से आगे नहीं रखी जाती।