Base64url, Base64 एन्कोडिंग का एक रूपांतर है जिसे विशेष रूप से URL, फ़ाइलनामों और अन्य ऐसे संदर्भों में उपयोग के लिए तैयार किया गया है जहाँ मानक Base64 के + और / वर्ण समस्या उत्पन्न करते हैं। RFC 4648 धारा 5 में परिभाषित, Base64url + को - (हाइफ़न) और / को _ (अंडरस्कोर) से बदलता है, और अंत के = पैडिंग वर्णों को हटा देता है। इसका परिणाम एक ऐसी स्ट्रिंग होती है जिसे URL क्वेरी पैरामीटर, फ़ाइलनाम या HTTP हेडर में अतिरिक्त percent-encoding की आवश्यकता के बिना सीधे एम्बेड किया जा सकता है।
मानक Base64 (RFC 4648 धारा 4) 64 वर्णों का उपयोग करता है: A-Z, a-z, 0-9, + और /। + और / वर्ण URL में आरक्षित हैं: क्वेरी स्ट्रिंग में + को रिक्त स्थान के रूप में समझा जाता है (application/x-www-form-urlencoded में), और / एक पथ-विभाजक है। इसलिए URL के अंदर मानक Base64 उपयोग करने पर इन वर्णों को percent-encode करना पड़ता है (%2B, %2F), जिससे स्ट्रिंग की लंबाई बढ़ती है और पठनीयता कम होती है। Base64url इस समस्या को पूरी तरह समाप्त करता है क्योंकि यह शुरू से ही URL-सुरक्षित वर्णों का उपयोग करता है।
Base64url का सबसे प्रमुख उपयोग JSON Web Tokens (JWT) में है। JWT के तीनों खंड — हेडर, पेलोड और हस्ताक्षर — Base64url-एन्कोडेड होते हैं। OAuth 2.0 PKCE code verifier, WebAuthn चैलेंज मान और कई API टोकन योजनाएँ भी Base64url पर निर्भर करती हैं। प्रमाणीकरण, प्राधिकरण या क्रिप्टोग्राफ़िक डेटा विनिमय पर कार्य करने वाले प्रत्येक डेवलपर के लिए इस एन्कोडिंग को समझना आवश्यक है।
यह Base64url टूल क्यों उपयोग करें?
Base64url और सादे पाठ या बाइनरी डेटा के बीच सीधे अपने ब्राउज़र में रूपांतरण करें। एन्कोडिंग और डीकोडिंग दोनों समर्थित हैं, पैडिंग और वर्ण प्रतिस्थापन स्वचालित रूप से संभाले जाते हैं।
⚡
तत्काल रूपांतरण
आउटपुट टाइप करते ही अपडेट होता है। टेक्स्ट को Base64url में एन्कोड करें या Base64url को वापस टेक्स्ट में डीकोड करें — बिना किसी देरी के, कोई फ़ॉर्म सबमिशन या पेज रीलोड नहीं।
🔗
URL-सुरक्षित आउटपुट
आउटपुट केवल ऐसे वर्णों का उपयोग करता है जो URL, फ़ाइलनामों और HTTP हेडर में सुरक्षित हैं: A-Z, a-z, 0-9, हाइफ़न और अंडरस्कोर। कोई percent-encoding आवश्यक नहीं।
🔒
गोपनीयता-प्रथम प्रसंस्करण
सभी एन्कोडिंग और डीकोडिंग आपके ब्राउज़र में स्थानीय रूप से चलती है। यहाँ पेस्ट किए गए JWT टोकन, OAuth गोपनीय कुंजियाँ और API कुंजियाँ किसी भी सर्वर पर कभी नहीं भेजी जातीं।
🏛️
मानक-अनुरूप
RFC 4648 धारा 5 को ठीक-ठीक लागू करता है: + और / की जगह - और _ उपयोग होते हैं, पैडिंग हटाई जाती है। JWT लाइब्रेरी, OAuth 2.0 PKCE और WebAuthn कार्यान्वयनों के साथ संगत।
Base64url के उपयोग के मामले
JWT टोकन जाँच
JWT के अलग-अलग खंड (हेडर, पेलोड) डीकोड करें ताकि दावे, समाप्ति समय और हस्ताक्षर एल्गोरिदम की जाँच हो सके — बिना JWT लाइब्रेरी आयात किए या हस्ताक्षर सत्यापित किए।
OAuth 2.0 PKCE प्रवाह
PKCE code_verifier और code_challenge मान उत्पन्न करें और सत्यापित करें। code_challenge_method S256 के लिए code_verifier के SHA-256 हैश का Base64url-एन्कोडेड रूप आवश्यक है।
WebAuthn / FIDO2 एकीकरण
WebAuthn चैलेंज, क्रेडेंशियल ID और प्रमाणन डेटा ब्राउज़र और relying party सर्वर के बीच Base64url स्ट्रिंग के रूप में भेजे जाते हैं। पंजीकरण और प्रमाणीकरण प्रवाहों को डीबग करने के लिए उन्हें डीकोड करें।
API टोकन निर्माण
पासवर्ड-रीसेट लिंक, ईमेल सत्यापन और सत्र पहचानकर्ताओं के लिए यादृच्छिक बाइट से URL-सुरक्षित टोकन बनाएँ। Base64url संक्षिप्त स्ट्रिंग उत्पन्न करता है जो बिना एस्केपिंग के URL में काम करती हैं।
DevOps और CI/CD पाइपलाइन
बाइनरी कॉन्फ़िगरेशन मान (प्रमाणपत्र, कुंजियाँ) को Base64url स्ट्रिंग के रूप में पर्यावरण चर या YAML फ़ाइलों में संग्रहीत करें। मानक Base64 के विपरीत, आउटपुट में ऐसे कोई वर्ण नहीं होते जो शेल विस्तार या YAML सिंटैक्स से टकराएँ।
डेटा इंजीनियरिंग
बाइनरी पहचानकर्ताओं, हैश या चेकसम को Base64url में एन्कोड करें ताकि फ़ाइलनामों, डेटाबेस कुंजियों या CSV स्तंभों में उपयोग हो सके, जहाँ + और / वर्ण पार्सिंग को बाधित करते या एस्केपिंग की आवश्यकता होती।
मानक Base64 बनाम Base64url
Base64url, मानक Base64 से ठीक तीन तरीकों से भिन्न है। एन्कोडिंग एल्गोरिदम समान है — केवल वर्णमाला और पैडिंग व्यवहार बदलता है:
विशेषता
मानक (RFC 4648 §4)
Base64url (RFC 4648 §5)
Index 62
+
-
Index 63
/
_
Padding
= (required)
Omitted
इन तीन अंतरों का अर्थ है कि मानक Base64 और Base64url के बीच रूपांतरण सरल है: + को - से, / को _ से बदलें और अंत के = वर्ण हटा दें। विपरीत दिशा में, - को + से, _ को / से बदलें और पैडिंग पुनः जोड़ें ताकि लंबाई 4 की गुणज बने। अधिकांश भाषाएँ मूल Base64url समर्थन प्रदान करती हैं, इसलिए मैन्युअल रूपांतरण अनावश्यक है।
एन्कोडिंग तुलना तालिका
नीचे की तालिका एक ही इनपुट को मानक Base64 और Base64url दोनों से एन्कोड करके दिखाती है। ध्यान दें कि URL-safe रूपांतर में पैडिंग वर्ण (=) हटा दिए जाते हैं और + / / को - / _ से बदला जाता है:
इनपुट
मानक Base64
Base64url (बिना पैडिंग)
Hello
SGVsbG8=
SGVsbG8
A
QQ==
QQ
1+1=2
MSsxPTI=
MSsxPTI
subject?ref=1
c3ViamVjdD9yZWY9MQ==
c3ViamVjdD9yZWY9MQ
ð (thumbs up)
8J+RjQ==
8J-RjQ
कोड उदाहरण
लोकप्रिय भाषाओं में Base64url स्ट्रिंग एन्कोड और डीकोड कैसे करें। प्रत्येक उदाहरण ऐसा आउटपुट देता है जो URL, फ़ाइलनामों और HTTP हेडर में उपयोग के लिए सुरक्षित है:
package main
import (
"encoding/base64"
"fmt"
)
func main() {
// Encode to Base64url (no padding)
encoded := base64.RawURLEncoding.EncodeToString([]byte("Hello!"))
fmt.Println(encoded) // → "SGVsbG8h"
// Decode from Base64url
decoded, _ := base64.RawURLEncoding.DecodeString("SGVsbG8h")
fmt.Println(string(decoded)) // → "Hello!"
}
अक्सर पूछे जाने वाले प्रश्न
Base64 और Base64url में क्या अंतर है?
Base64url, मानक Base64 वर्णमाला से + को - और / को _ से बदलता है, और अंत के = पैडिंग वर्णों को हटा देता है। इससे आउटपुट URL, क्वेरी पैरामीटर, फ़ाइलनामों और HTTP हेडर में अतिरिक्त एन्कोडिंग के बिना उपयोग के लिए सुरक्षित हो जाता है। अंतर्निहित एल्गोरिदम (बाइट को 6-बिट समूहों में विभाजित करके ASCII वर्णों पर मैप करना) समान है।
JWT टोकन मानक Base64 की जगह Base64url क्यों उपयोग करते हैं?
JWT अक्सर URL क्वेरी पैरामीटर और HTTP Authorization हेडर में भेजे जाते हैं। मानक Base64 के + और / वर्णों को URL में percent-encode करना पड़ता, जिससे लंबाई बढ़ती और सरल स्ट्रिंग तुलना टूट जाती। JWT विशिष्टता (RFC 7519) Base64url को बिना पैडिंग के अनिवार्य करती है ताकि टोकन संक्षिप्त और डिफ़ॉल्ट रूप से URL-सुरक्षित रहें।
मानक Base64 को Base64url में कैसे बदलें?
प्रत्येक + को - से, प्रत्येक / को _ से बदलें और सभी अंत के = वर्ण हटा दें। JavaScript में: base64.replace(/\+/g, '-').replace(/\//g, '_').replace(/=+$/, '')। Python में: base64.urlsafe_b64encode(data).rstrip(b'=')। अधिकांश आधुनिक भाषाएँ एक समर्पित Base64url एन्कोडिंग फ़ंक्शन भी प्रदान करती हैं।
क्या Base64url एन्कोडिंग उलटाव योग्य है?
हाँ, Base64url पूरी तरह उलटाव योग्य है। डीकोड करने के लिए, - को + से और _ को / से बदलें, लंबाई को 4 की गुणज बनाने के लिए = पैडिंग वर्ण पुनः जोड़ें, फिर मानक Base64 की तरह डीकोड करें। डीकोड किया गया आउटपुट मूल इनपुट के बाइट-दर-बाइट समान होता है।
क्या मैं डेटा एन्क्रिप्ट करने के लिए Base64url उपयोग कर सकता हूँ?
नहीं। Base64url एक एन्कोडिंग है, एन्क्रिप्शन नहीं। यह बाइनरी डेटा को बिना किसी गोपनीयता के टेक्स्ट-सुरक्षित रूप में बदलता है — कोई भी इसे डीकोड कर सकता है। यदि आपको डेटा सुरक्षित करना है, तो पहले उचित एल्गोरिदम (AES, ChaCha20) से एन्क्रिप्ट करें, फिर परिवहन के लिए सिफ़रटेक्स्ट को Base64url-एन्कोड करें।
Base64url में पैडिंग क्यों हटाई जाती है?
पैडिंग वर्ण (=) का कोई उद्देश्य नहीं होता जब डीकोडर स्ट्रिंग की लंबाई से लापता बाइट की संख्या की गणना कर सकता है: (4 - length % 4) % 4 आवश्यक पैडिंग देता है। पैडिंग हटाने से स्ट्रिंग छोटी होती है और = वर्षों से बचा जाता है जिन्हें URL में percent-encode करना पड़ता। RFC 4648 धारा 5 Base64url में पैडिंग हटाने की स्पष्ट अनुमति देती है।
मैं अपने कोड में पैडिंग वाली Base64url स्ट्रिंग कैसे संभालूँ?
कुछ प्रणालियाँ Base64url स्ट्रिंग में = पैडिंग बनाए रखती हैं। अधिकांश डीकोडर इसे सही ढंग से संभालते हैं। यदि आपका डीकोडर नहीं संभालता, तो डीकोड करने से पहले अंत के = हटा दें। इसके विपरीत, यदि किसी लाइब्रेरी को पैडिंग चाहिए, तो इसे गणना करके जोड़ें: const padded = str + '='.repeat((4 - str.length % 4) % 4)। यह काम करता है क्योंकि पैडिंग की संख्या स्ट्रिंग की लंबाई से निर्धारित होती है।