ईमेल वैलिडेटर (syntax + सामान्य typo detection)
ईमेल टाइप करें — syntax सही है या नहीं जाँचें, 'gmial.com' → 'gmail.com' जैसे domain typos पकड़ें। local-part, domain, TLD breakdown और RFC सीमा उल्लंघन की चेतावनी।
- Local part
- user
- Domain
- example.com
- TLD
- com
- Plus tag (+)
- —
कैसे काम करता है
यह validator क्या करता है (और क्या नहीं)
ईमेल syntax validation जाँचता है कि 'name@domain.tld' RFC 5322 के structural rules का पालन करता है या नहीं। हम एक pragmatic regex उपयोग करते हैं जो वास्तविक दुनिया के लगभग सभी typos पकड़ता है, साथ ही plus tags, dots और unusual TLDs वाले legitimate addresses के लिए भी लचीला रहता है।
यह tool क्या नहीं कर सकता: यह confirm नहीं कर सकता कि address पर वास्तव में mail आता है। इसके लिए real email भेजना या SMTP check करना पड़ता है — दोनों server-side code माँगते हैं और false positives का जोखिम होता है। Syntax validation typos सस्ते में पकड़ता है; deliverability जाँचने के लिए अलग approach चाहिए।
सामान्य typo detection
हम प्रमुख free email providers में typos देखते हैं — 'gmail.com' की जगह 'gmial.com', 'yahoo.com' की जगह 'yaho.com' आदि। Email signup typos में से लगभग 95% इन कुछ providers के domain typos होते हैं। Client-side पर पकड़ने से bounced welcome email और असहज 'कृपया अपना address जाँचें' follow-up से बचा जाता है।
यदि आप signup form बना रहे हैं, तो submit करने से पहले यही logic चलाएँ। 'क्या आपका मतलब था...?' suggestion दिखाएँ और user को accept या override करने दें। mature signup flows यह routinely करते हैं; इससे email deliverability ध्यान देने योग्य रूप से सुधरती है।
Local part के नियम
Plus tag ('user+filter@gmail.com'): प्रमुख providers द्वारा व्यापक रूप से support किया जाता है। विभिन्न sign-ups के लिए unique addresses बनाने में उपयोगी, single inbox बनाए रखते हुए।
Dots ('user.name@gmail.com'): Gmail इन्हें same address मानता है (dots ignore होते हैं), लेकिन अन्य providers इन्हें अलग addresses मान सकते हैं। Gmail के बाहर dot-equivalence पर निर्भर न रहें।
लंबाई: RFC 5321 local part को 64 characters और पूरे address को 254 characters तक सीमित करता है। जब ये exceed होते हैं तो हम चेतावनी देते हैं — अधिकांश servers लंबे addresses अस्वीकार करते हैं।
Case sensitivity: RFC के अनुसार local part case-sensitive है, लेकिन अधिकांश providers इसे case-insensitive मानते हैं। Domain हमेशा case-insensitive होता है।
अक्सर पूछे जाने वाले प्रश्न
›क्या यह confirm करता है कि ईमेल exist करता है?
नहीं — केवल syntax। Inbox exist करता है या नहीं जाँचने के लिए server-side SMTP check या verification email भेजना पड़ता है। यह tool typos सस्ते में पकड़ता है।
›'a@b.co' क्यों accept हुआ?
क्योंकि यह technically valid syntax है। TLD '.co' real है (कोलंबिया)। Syntax validation real-but-rare TLDs filter नहीं कर सकती।
›Unicode ईमेल (जैसे user@उदाहरण.भारत) के बारे में क्या?
Internationalized email addresses RFC 6531 के अनुसार valid हैं, लेकिन यहाँ उपयोग किया गया regex उन्हें accept नहीं करता। अधिकांश form backends भी नहीं करते। Unicode-friendly validation के लिए dedicated library उपयोग करें।
›Plus tag क्या है?
+ और @ के बीच की कोई भी चीज़ Gmail और कई providers द्वारा routing के हिस्से के रूप में treat की जाती है। user+toolify@gmail.com, user@gmail.com पर जाता है लेकिन आप +toolify suffix से filter कर सकते हैं।
›Gmail dots क्यों ignore करता है?
यह Gmail की historical policy है। user.name@gmail.com और username@gmail.com same inbox पर deliver होते हैं। अन्य providers (Yahoo, Outlook) इन्हें अलग मानते हैं।
›सबसे लंबा valid ईमेल क्या है?
RFC 5321 के अनुसार कुल 254 characters। Local part ≤ 64। अधिकांश servers लंबे addresses reject करते हैं।
›क्या data मेरे browser से बाहर जाता है?
नहीं। Validation locally चलती है; कुछ भी किसी server को नहीं भेजा जाता।
›क्या मैं bulk validate कर सकता हूँ?
इस tool में नहीं — एक बार में एक address paste करें। Lists के लिए, script या dedicated bulk-validation service उपयोग करें (उन लोगों की consent के साथ जिनके addresses आप जाँच रहे हैं)।
संबंधित टूल्स
अंतिम अपडेट: