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

नहीं — और यही इस साइट के होने की वजह है। पूरा कन्वर्ज़न WebAssembly के ज़रिए आपके ब्राउज़र में ही होता है, इसलिए फ़ाइलें आपके डिवाइस से बाहर नहीं जातीं और बीच में कोई सर्वर नहीं आता। पेज लोड होने के बाद टूल बिना इंटरनेट के भी चलता है, और डिवाइस की मेमोरी के अलावा साइज़ की कोई सीमा नहीं है।

जब आपके स्टैक की कोई चीज़ — कोई पुराना ब्राउज़र जिसे सपोर्ट करना ज़रूरी है, कोई CMS, ईमेल टूल या इमेज CDN प्लान — WebP तो सँभाल लेती है पर AVIF नहीं। आप थोड़ा सा कम्प्रेशन छोड़ते हैं और बदले में कई साल की अतिरिक्त कम्पैटिबिलिटी पाते हैं।

आम तौर पर AVIF से 20–50% बड़ी — फिर भी उसी इमेज की JPG या PNG से कहीं छोटी। यह दोहरा लॉसी कन्वर्ज़न आँख के लिए साफ़ रहे, इसके लिए मैंने डिफ़ॉल्ट क्वालिटी 82 रखी है।

हाँ — दोनों फ़ॉर्मैट पूरा अल्फा चैनल रखते हैं, इसलिए लोगो और कटआउट जस के तस पहुँचते हैं। फ़ॉर्मैट की यह वह जोड़ी है जहाँ ट्रांसपेरेंसी रास्ते में कभी नहीं खोती।

फ़ॉलबैक ब्राउज़रों और CMS के लिए हो तो WebP: अल्फा रहता है और फ़ाइल JPG से 3–4 गुना छोटी। फ़ॉलबैक इंसानों के लिए हो — अटैचमेंट, अपलोड, ऑफ़िस डॉक्यूमेंट — तो AVIF को JPG में बदलें, क्योंकि "हर मौजूदा ब्राउज़र" में भी वह ढेर सारा सॉफ़्टवेयर नहीं आता जो लोग सचमुच चलाते हैं।

दो ईमानदार सूरतें: आपकी इमेज छूने वाली हर चीज़ पहले से AVIF सँभालती हो, तो आप 20–50% बाइट यों ही बढ़ा रहे हैं; और AVIF ख़ुद किसी री-एन्कोड से बनी हो, तो यह दूसरा लॉसी दौर बारीक बनावट को दिखने लायक़ नरम कर देता है। दूसरी सूरत में असली ओरिजिनल खोजकर उसी से नए सिरे से कन्वर्ट करें।