आँकड़ों और विज्ञापन के लिए कुकीज़
हम आँकड़ों और विज्ञापन के लिए कुकीज़ इस्तेमाल करते हैं, दोनों Google को जाती हैं। मना करने से आपको दिखने वाली किसी चीज़ में कोई फ़र्क़ नहीं पड़ता।निजता पेज पढ़ें
यहाँ आप SVG को WebP में बदलते हैं, मुफ़्त और बिना खाते के: फ़ाइल ऊपर छोड़िए और कुछ ही सेकंड में नतीजा डाउनलोड के लिए तैयार मिलेगा। कन्वर्ज़न आपके अपने ब्राउज़र के भीतर होता है, इसलिए फ़ाइल कभी अपलोड नहीं होती। यह Windows, macOS और Linux पर वैसे ही चलता है जैसे iPhone और Android पर, और कनेक्शन काट देने पर भी चलता रहता है।
एक बार में 100 फ़ाइलें। फ़ॉर्मेट अलग-अलग हों तो भी चलेगा।
ये एक के बाद एक बदलती हैं और साथ में एक ZIP बनकर उतरती हैं।
SVG से WebP
SVG निर्देशों का सेट है — यह पथ खींचो, यह आकार भरो, यह लाइन खींचो — जिसका अपना कोई रेज़ोल्यूशन नहीं। रेंडरिंग एक ख़ास आकार पर उन निर्देशों को मानती है और नतीजे को पिक्सेल के तौर पर दर्ज करती है, और उस पल से ड्रॉइंग चली जाती है, सिर्फ़ तस्वीर बचती है।
तो बदलाव के समय चुना आकार ही आपके पास बचा आकार है। बाद में WebP बड़ी करना सिर्फ़ बीच के पिक्सेल गढ़ सकता है, जो ठीक वही हालत है जिससे बचने के लिए वेक्टर आर्टवर्क बना। स्केल सही रखना ही इस बदलाव का पूरा हुनर है।
फ़ोन स्क्रीन हर CSS पिक्सेल में दो-तीन डिवाइस पिक्सेल भर देती है, तो ठीक अपने प्रदर्शन आकार पर रेंडर की तस्वीर ज़्यादातर देखने वाले डिवाइस पर नर्म दिखती है। दो या तीन गुना पर रेंडर करके ब्राउज़र से नीचे स्केल करवाना आम रिवाज़ है और सुनने से कम ख़र्च करता है।
अपवाद है सच में बड़ी चीज़ें। पूरी-चौड़ाई का हीरो 3× पर रेंडर होकर ऐसी फ़ाइल बनाता है जिसे किसी को डाउनलोड नहीं करना चाहिए; वहाँ 2× पर रेंडर कीजिए और स्वीकार लीजिए, या सोचिए क्या SVG सीधे परोसी जा सकती है।
SVG अपने फ़ॉन्ट का नाम लेती है, उन्हें रखती नहीं। जब रेंडरर के पास फ़ॉन्ट होता है, टेक्स्ट सही खिंचता है; न होने पर कोई और अलग चौड़ाई पर बदल दिया जाता है — तो लाइसेंस वाले टाइपफ़ेस में सजा वर्डमार्क सामान्य sans-serif में आता है, ग़लत चौड़ाई पर, आसपास का लेआउट टूटा हुआ।
हल ड्रॉइंग प्रोग्राम में है, एक्सपोर्ट से पहले: टेक्स्ट को outline में बदलिए, ताकि अक्षर पथ बन जाएँ और किसी पर निर्भर न रहें। टेक्स्ट संपादन-योग्य होना बंद हो जाता है और भरोसेमंद बनने लगता है, जो लोगो के लिए सही सौदा है।
यहाँ बनी WebP हमेशा लॉसी है — क्वालिटी नियंत्रण तय करता है एनकोडर कितना कसकर दबाता है, और इस जोड़ी में कोई लॉसलेस मोड नहीं। डिफ़ॉल्ट 82 तस्वीरों के लिए ठीक किया गया है, और वेक्टर आर्टवर्क पर ग़लत जगह दिखता है: एक-पिक्सेल की लाइन में धब्बा आ जाता है, और दो फ़्लैट रंगों की सीमा पर बीच के पिक्सेल का हल्का घेरा बन जाता है।
लोगो, आइकन या चार्ट के लिए इसे 95 या ऊपर ले जाइए, और ये गड़बड़ी चली जाती है जबकि फ़ाइल छोटी रहती है, क्योंकि फ़्लैट रंग किसी भी सेटिंग पर अच्छे से सिमटता है। ग्रेडिएंट व नरम शेडिंग वाला इलस्ट्रेशन फ़ोटो जैसा व्यवहार करता है और उसे इसकी ज़रूरत नहीं।
अक्सर। अगर ड्रॉइंग लोगो, आइकन या आपके नियंत्रण वाले वेबपेज पर जाने वाला सादा इलस्ट्रेशन है, SVG आम तौर पर उसकी किसी भी रैस्टर से छोटी है, हर ज़ूम पर हर स्क्रीन पर साफ़, और CSS से दूसरी फ़ाइल बनाए बिना रंग बदलने लायक़।
बदलिए जब कुछ SVG मना करता है, और मना करने वाली चीज़ें हैं: सोशल मीडिया प्रीव्यू तस्वीरें तय आयाम पर PNG या JPG होनी चाहिए, ईमेल क्लाइंट भरोसेमंद नहीं, कई अपलोड फ़ॉर्म इस फ़ॉर्मेट को सिरे से नकारते हैं, और यूज़र अपलोड लेने वाले प्लेटफ़ॉर्म सुरक्षा वजहों से अक्सर मना करते हैं।
आइकन सेट में आते हैं, अकेले नहीं। पूरा फ़ोल्डर छोड़िए: हर फ़ाइल आपके चुने स्केल पर बारी-बारी रेंडर होती है, अपना नाम एक्सटेंशन बदलकर रखती है, और सब कुछ एक ZIP बनकर लौटता है, बिल्ड में डालने के लिए तैयार।
दो आदतें नतीजे स्थिर रखती हैं। हर आइकन को उसी स्केल पर रेंडर कीजिए, आँख से नहीं, ताकि सेट एक नज़र में जान-बूझकर बना दिखे। और SVG को स्रोत के तौर पर version control में रखिए — नए आकार पर पूरा सेट दोबारा बनाना फिर एक पास की क़ीमत लेता है, दोबारा बनाने की नहीं।
रेंडरिंग आपके अपने प्रोसेसर पर ब्राउज़र टैब में होती है। कुछ भी अपलोड नहीं होता, तो कोई कतार नहीं, कोई रोज़ाना गिनती नहीं, कोई अकाउंट नहीं — और कोई तीसरा पक्ष आपके अप्रकाशित ब्रांड एसेट नहीं रखता, जो लोगो के मामले में ज़्यादातर फ़ाइलों से बड़ी चिंता है।
इसका मतलब यह भी है दो सौ आइकन का फ़ोल्डर उतनी तेज़ी से बदलता है जितनी तेज़ी से आपकी मशीन खींच सकती है, न कि उतनी जितनी तेज़ी से वे अपलोड और वापस मँगाए जा सकें।
SVG का रेंडर बैकग्राउंड पूरी तरह पारदर्शी है, तो जो भी पारदर्शिता ड्रॉइंग में है वह WebP के अल्फ़ा चैनल में सही तरीक़े से आती है — कोई सफ़ेद घेरा नहीं, कोई काला किनारा नहीं। यह किसी लोगो को अलग-अलग बैकग्राउंड रंग वाले पेज पर बार-बार इस्तेमाल करने के लिए काम की बात है।
अगर लक्ष्य ठोस बैकग्राउंड वाला हीरो या सोशल-प्रीव्यू तस्वीर है, पारदर्शिता को WebP पर छोड़ने की बजाय SVG में ही एक ठोस background आयत जोड़ना बेहतर है, ताकि हर व्यूअर एक जैसा नतीजा दिखाए — कुछ जगह अल्फ़ा compositing थोड़ा अलग दिखता है।
| SVG | WebP | |
|---|---|---|
| पूरा नाम | Scalable Vector Graphics | WebP तस्वीर |
| फ़ाइल एक्सटेंशन | .svg | .webp |
| मीडिया टाइप | image/svg+xml | image/webp |
| कंप्रेशन | बिना कंप्रेशन | सेटिंग के हिसाब से दोनों में से कोई भी |
| पहली बार प्रकाशित | 2001 | 2010 |
| प्रकाशक | W3C | |
| विनिर्देश | SVG 1.1 | RFC 9649 |
| लाइसेंस | खुला मानक | खुला मानक |
| आज की स्थिति | मौजूदा | मौजूदा |
| बिट डेप्थ | — | 8 |
| रंग जो यह दर्ज कर सकता है | RGB | RGB, YCbCr |
| सबसे बड़ी इमेज | — | हर तरफ़ 16,383 px |
| ब्राउज़र में खुलता है | हर ब्राउज़र | हर ब्राउज़र |
| इसकी जगह विचारणीय | PNG, PDF | AVIF, JPG, PNG |
SVG आकृतियों का वर्णन करता है और WebP बिंदु सँभालता है। नतीजा उसी नाप पर साफ़ है जिस पर वह बना, उससे बड़े पर नहीं: बाद में बढ़ाने पर बीच के बिंदु सिर्फ़ गढ़े जा सकते हैं — इसीलिए यहाँ निर्यात की नाप बाक़ी ज़्यादातर कन्वर्ज़न से ज़्यादा मायने रखती है।
परतें आपस में मिला दी जाती हैं। SVG उन्हें अलग और बदलने लायक़ रखता है; WebP नतीजा रखता है — यानी जिस भी काम के लिए किसी परत को खिसकाना पड़े, वह पहले ही निपटा लेना होगा।
पारदर्शिता बनी रहती है। SVG और WebP — दोनों अल्फ़ा चैनल सँभालते हैं: काटा हुआ हिस्सा कटा ही रहता है और उसके पीछे कुछ भरा नहीं जाता।
एनिमेशन बना रहता है। SVG और WebP — दोनों कई फ़्रेम ढोते हैं, इसलिए नतीजा अब भी चलता है।
दोनों तरफ़ के प्रोग्राम अलग हैं: SVG फ़ाइल Inkscape, Adobe Illustrator और Figma में खुलती है और WebP फ़ाइल Adobe Photoshop, GIMP और Squoosh में — यानी नतीजा जिसके पास जाएगा, उसे दूसरी सूची में से कोई प्रोग्राम चाहिए होगा।
SVG W3C का फ़ॉर्मेट है, जो 2001 में आया। यह SVG 1.1 में तय किया गया है, और अगर फ़ाइल को उस औज़ार से ज़्यादा जीना है जिसने उसे लिखा, तो यह बात क़ीमती है।
WebP Google का है और 2010 से चला आ रहा है, और RFC 9649 में तय किया गया है। Adobe Photoshop, GIMP और Squoosh इस फ़ॉर्मेट को पढ़ लेते है।
नहीं। यह कन्वर्ज़न पूरी तरह आपके ब्राउज़र में होता है, इसलिए फ़ाइल आपके डिवाइस से बाहर नहीं जाती। आप ख़ुद जाँच सकते हैं: डेवलपर टूल्स का नेटवर्क टैब खोलिए और कुछ बदल कर देखिए। आपको पेज ख़ुद दिखेगा और आँकड़ों तथा विज्ञापन के वे अनुरोध दिखेंगे जिनसे इस सेवा का ख़र्च निकलता है — और एक भी ऐसा अनुरोध नहीं जो आपकी फ़ाइल साथ ले जा रहा हो। इस जोड़ी के पीछे resvg है, Rust में लिखा एक सख़्त SVG रेंडरर; आपका ब्राउज़र इसे एक बार उतारता है और फिर सहेज कर रखता है।
हाँ। न खाता, न वॉटरमार्क, और न कोई रोज़ का कोटा जो ख़त्म हो: यह आपकी अपनी मशीन पर चलता है, इसलिए आप जितनी बार चाहें लौट सकते हैं। ब्राउज़र 100 MB तक की फ़ाइलें सँभालता है, एक बार में 100। resvg आपकी अपनी मशीन पर उतरता है और वहीं चलता है — इसीलिए उस पर कोई गिनती नहीं है।
SVG और WebP सामग्री का वर्णन बुनियादी तौर पर अलग-अलग तरीक़ों से करते हैं। इसलिए यह कन्वर्ज़न नक़ल नहीं, पुनर्निर्माण है: ईमानदार, पर बाइट-दर-बाइट एक जैसा नहीं। लिखावट उन्हीं फ़ॉन्ट से बनाई जाती है जो फ़ाइल के अंदर हैं; बाक़ी के लिए कोई विकल्प आ जाता है।
SVG आकृतियों का वर्णन करता है और WebP बिंदु सँभालता है। नतीजा उसी नाप पर साफ़ है जिस पर वह बना, उससे बड़े पर नहीं: बाद में बढ़ाने पर बीच के बिंदु सिर्फ़ गढ़े जा सकते हैं — इसीलिए यहाँ निर्यात की नाप बाक़ी ज़्यादातर कन्वर्ज़न से ज़्यादा मायने रखती है।
परतें आपस में मिला दी जाती हैं। SVG उन्हें अलग और बदलने लायक़ रखता है; WebP नतीजा रखता है — यानी जिस भी काम के लिए किसी परत को खिसकाना पड़े, वह पहले ही निपटा लेना होगा।
पारदर्शिता बनी रहती है। SVG और WebP — दोनों अल्फ़ा चैनल सँभालते हैं: काटा हुआ हिस्सा कटा ही रहता है और उसके पीछे कुछ भरा नहीं जाता।
इस पेज पर SVG और WebP के बारे में जो कहा गया है, वह जाँचा जा सकता है, और ये रहे वे दस्तावेज़ जो उसे तय करते हैं।