ईमेल अटैचमेंट का आकार और सीमा जाँचें

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

आपके विवरण

परिणाम पर जाएँ
अटैचमेंट

हर अटैचमेंट अलग से Base64 में एन्कोड किया जाता है। पंक्ति विरामों का अनुमान CRLF के साथ लगाया जाता है और हर गैर-खाली अटैचमेंट के अंत में एक पंक्ति विराम शामिल किया जाता है। यह पूर्ण MIME संदेश नहीं है।

परिणाम

संख्याएँ चुनी गई भाषा के दशमलव और अंक-समूह विभाजकों के साथ दर्ज करें। आप उस भाषा के संबंधित अंकों का भी उपयोग कर सकते हैं।

अटैचमेंट और संदेश का आकार अलग क्यों होता है

भेजते समय मुख्य रूप से उस संदेश का आकार बढ़ता है जिसमें आपकी PDF शामिल होती है। ईमेल मूल रूप से टेक्स्ट के लिए बनाया गया था। इसलिए आपका ईमेल प्रोग्राम फ़ाइल अटैचमेंट को MIME फ़ॉर्मैट में पैक करता है और आम तौर पर Base64 की मदद से बाइनरी डेटा को साधारण टेक्स्ट वर्णों में बदलता है। इसमें फ़ाइल के हर 3 बाइट से 4 वर्ण बनते हैं, और इन वर्णों को ऐसी लाइनों में बाँटा जाता है जिनके अंत में लाइन समाप्ति के वर्ण होते हैं। Base64 एन्कोडिंग को वापस मूल रूप में बदला जा सकता है: डिकोड करने पर ठीक वही मूल बाइट फिर मिलते हैं। पूरे संदेश में हेडर, संदेश का टेक्स्ट और अलग-अलग हिस्सों के बीच के विभाजक भी जुड़ते हैं।

इस तरह संदेश आपके चुने हुए अटैचमेंट से काफ़ी बड़ा हो सकता है। एक जर्मन भाषा के फ़ोरम में किसी ने पूछा था कि 20.1-MB की PDF भेजने पर ईमेल का आकार 27.5 MB क्यों हो गया। यदि आप इस कैलकुलेटर में 2,01,00,000 बाइट की गणना लाइन ब्रेक के साथ और अतिरिक्त बाइट के बिना करें, तो 2,68,00,000 बाइट का Base64 डेटा और 7,05,264 बाइट की लाइन समाप्तियाँ मिलती हैं। कुल मिलाकर यह 2,75,05,264 बाइट, यानी लगभग 27.51 MB होता है। यह गणना दिखाती है कि आकार इस स्तर तक कैसे पहुँचता है। यह एक मॉडल गणना है, उस विशेष ईमेल का विश्लेषण नहीं।

अनुमान किन हिस्सों से बनता है

हर फ़ाइल को अलग पंक्ति में रखें, क्योंकि हर संलग्न फ़ाइल को अलग से एन्कोड किया जाता है। आप आकार B, KB, MB, GB, MiB या GiB जैसी इकाइयों में दे सकते हैं। कैलकुलेटर MB की गणना दशमलव आधार पर करता है: 1 MB बराबर 10,00,000 बाइट है। MiB की गणना बाइनरी आधार पर होती है: 1 MiB बराबर 10,48,576 बाइट है। रूपांतरण के बाद पूरे बाइटों की संख्या मिलनी चाहिए। संख्या लिखते समय ध्यान रखें कि बिंदु दशमलव चिह्न है, इसलिए 1.000 का अर्थ एक है। एक हज़ार के लिए 1,000 या 1,000.00 लिखें। संख्या वाले खाने में इकाई न जोड़ें।

  1. मूल आकार: बाइट में आपके सभी अटैचमेंट का कुल आकार। यही शुरुआती मान है और अटैचमेंट की सीमा से तुलना के लिए इस्तेमाल होता है।
  2. Base64 डेटा: n बाइट वाले अटैचमेंट से 4 × ऊपर की ओर पूर्णांकित(n ÷ 3) वर्ण बनते हैं। अंत में बचे बाइट से तीन का पूरा समूह न बन पाए, तो पैडिंग अंतिम चार-वर्ण वाले समूह को पूरा करती है।
  3. लाइन समाप्तियाँ: “पंक्ति विराम” चालू होने पर, जो डिफ़ॉल्ट सेटिंग है, कैलकुलेटर हर अटैचमेंट के वर्णों को अधिकतम 76 वर्णों वाली लाइनों में बाँटता है। हर लाइन के लिए वह CRLF लाइन समाप्ति के 2 बाइट गिनता है, अंतिम लाइन के लिए भी।
  4. अतिरिक्त बाइट: टेक्स्ट, हेडर और संदेश के अन्य हिस्सों के लिए आपका अपना मान। डिफ़ॉल्ट मान 0 है।
  5. अनुमान: सभी अटैचमेंट का Base64 डेटा और लाइन समाप्तियाँ, साथ में अतिरिक्त बाइट।
गणना का उदाहरण: 1,00,00,000 बाइट का एक अटैचमेंट, 76 वर्णों के बाद लाइन ब्रेक और मनमाने तौर पर माने गए 1,000 अतिरिक्त बाइट। परिणाम एक अनुमान है, किसी ईमेल का मापा हुआ आकार नहीं।
घटकबाइटमान कैसे बनता है
मूल अटैचमेंट1,00,00,000PDF फ़ाइल का आकार, बिना कुछ जोड़े शुरुआती मान
Base64 डेटा1,33,33,3364 × ऊपर की ओर पूर्णांकित(1,00,00,000 ÷ 3), जिसमें 33,33,336 बाइट की आकार वृद्धि शामिल है
लाइन समाप्तियाँ (CRLF)3,50,8781,75,439 लाइनें × 2 बाइट
अतिरिक्त बाइट1,000टेक्स्ट और हेडर के लिए अपनी धारणा
अनुमानित संदेश1,36,85,2141,33,33,336 + 3,50,878 + 1,000

क्या Base64 का आकार हमेशा ठीक एक तिहाई अधिक होता है?

लगभग इतना ही। बड़ी फ़ाइलों में 3 बाइट से 4 वर्ण बनने का अनुपात 33⅓ % की वृद्धि के करीब पहुँचता है। लाइन ब्रेक के बिना 1,00,00,000 बाइट से ठीक 1,33,33,336 बाइट बनते हैं, यानी लगभग 33.33 % अधिक। ठीक एक तिहाई से यह मामूली अंतर पैडिंग के कारण होता है। लाइन समाप्तियों के साथ आकार 1,36,84,214 बाइट होता है, यानी लगभग 36.8 % अधिक। इसलिए लगभग 37 % वाले सामान्य अनुमान एन्कोड किए गए डेटा और लाइन ब्रेक के संयुक्त आकार को बताते हैं। ये लाइन की लंबाई और लाइन समाप्ति पर निर्भर करते हैं तथा इनमें हेडर या टेक्स्ट शामिल नहीं होते।

छोटी फ़ाइलों के लिए कोई निश्चित गुणक बिल्कुल उपयोगी नहीं रहता। 1 बाइट का अटैचमेंट 4 Base64 वर्णों और 2 बाइट की लाइन समाप्ति में बदलकर कुल 6 बाइट हो जाता है। इसलिए कैलकुलेटर सभी आकारों को एक सामान्य मान से गुणा करने के बजाय हर अटैचमेंट की सटीक गणना करता है।

कई अटैचमेंट: हर फ़ाइल की अलग गणना

अटैचमेंट को एक बड़े ब्लॉक में जोड़ने के बजाय हर अटैचमेंट अलग से एन्कोड किया जाता है। इसलिए हर फ़ाइल की अपनी पैडिंग और अपनी अंतिम लाइन समाप्ति होती है। यह बात सबसे स्पष्ट रूप से उस सीमांत उदाहरण में दिखती है जिसमें दो फ़ाइलें हैं और हर फ़ाइल का आकार 1 बाइट है।

लाइन ब्रेक के साथ और अतिरिक्त बाइट के बिना सीमांत उदाहरण। दूसरी पंक्ति केवल समझाने के लिए की गई तुलना है; वह कैलकुलेटर की गणना का तरीका नहीं दिखाती।
स्थितिBase64 डेटालाइन समाप्तियाँकुल
दो फ़ाइलें, हर एक का आकार 1 बाइट, अलग-अलग एन्कोड की गईं8 बाइट4 बाइट12 बाइट
तुलना: वही 2 बाइट एक ही फ़ाइल के रूप में4 बाइट2 बाइट6 बाइट

एक बड़ी PDF में इन कुछ बाइट का असर बहुत कम होता है। लेकिन कई छोटी फ़ाइलों में ये जुड़ते जाते हैं।

76 वर्णों की लाइन लंबाई वह अधिकतम लंबाई है जिसे MIME मानक Base64 लाइनों के लिए निर्धारित करता है। अंतिम लाइन के बाद भी CRLF गिनना इस कैलकुलेटर का तय किया हुआ नियम है। छोटे आकार की लाइनें इस्तेमाल करने वाले या अंतिम लाइन समाप्ति को अलग ढंग से रखने वाले ईमेल प्रोग्रामों में मान कुछ अलग हो सकते हैं। एक और आम ग़लतफ़हमी: Base64 किसी चीज़ को एन्क्रिप्ट नहीं करता। यह केवल एन्कोडिंग है, जिसे बिना किसी कुंजी के मूल रूप में बदला जा सकता है, और यह आपके अटैचमेंट की सामग्री की सुरक्षा नहीं करता।

सही आकार सीमा से तुलना करें

आकार सीमा आपको एक संख्या तो बताती है, लेकिन हमेशा यह नहीं बताती कि वह किस पर लागू होती है। कुछ नियम मूल अटैचमेंट के कुल आकार को सीमित करते हैं, यानी उन फ़ाइल आकारों को जो आपका ईमेल प्रोग्राम दिखाता है। दूसरे नियम एन्कोड किए गए अटैचमेंट, टेक्स्ट और हेडर सहित पूरे संदेश को सीमित करते हैं। इसलिए कैलकुलेटर में आप चुनते हैं कि सीमा की तुलना किससे की जाए। पहले से भरा हुआ 25 MB का मान केवल शुरुआती मान है, किसी विशेष सेवा प्रदाता की निर्धारित सीमा नहीं। सीमा के ठीक बराबर परिणाम को भी “सीमा के भीतर” माना जाता है।

इसलिए एक ही फ़ाइल एक नियम का पालन कर सकती है और दूसरे की सीमा पार कर सकती है; इसमें कोई विरोधाभास नहीं है।

उदाहरण के लिए मानी गई 10 MB की काल्पनिक सीमा, किसी सेवा प्रदाता का नियम नहीं। फ़ाइल और धारणाएँ ऊपर दिए गए गणना के उदाहरण जैसी हैं। इससे यह जाँच नहीं होती कि ईमेल पहुँचेगा या नहीं।
सीमा किस पर लागू हैसीमातुलना किया गया मानपरिणाम
मूल अटैचमेंट1,00,00,000 बाइट1,00,00,000 बाइटसीमा के भीतर, ठीक सीमा के बराबर
अनुमानित संदेश1,00,00,000 बाइट1,36,85,214 बाइटसीमा से 36,85,214 बाइट अधिक

अलग-अलग आधारों पर लागू होने वाले दो वास्तविक नियम

  • Gmail: अटैचमेंट के बारे में जर्मन भाषा की Gmail सहायता के अनुसार (13. अक्टूबर 2026 को देखा गया), निजी खातों में सभी अटैचमेंट का कुल आकार 25 MB तक हो सकता है। इसका अर्थ अटैचमेंट का कुल आकार है, इसलिए यहाँ मूल अटैचमेंट से तुलना करना सही है। Google Workspace खातों के लिए सीमाएँ व्यवस्थापक तय करता है। कुल आकार इससे अधिक होने पर अटैचमेंट की जगह Google Drive लिंक लगा दिया जाता है।
  • एर्लांगेन-न्यूर्नबर्ग विश्वविद्यालय का RRZE: ईमेल अटैचमेंट की आकार सीमा से संबंधित निर्देश (13. अक्टूबर 2026 को देखा गया) RRZE सर्वरों पर आने और जाने वाले ईमेल के लिए पूरे ईमेल का अधिकतम आकार 20 MB बताते हैं। यहाँ अनुमानित संदेश से तुलना करें और उचित रूप से अतिरिक्त बाइट भी दर्ज करें।

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

पूरे संदेश के लिए अभी और क्या शामिल होना बाकी है

अकेला एन्कोड किया गया अटैचमेंट पूरा ईमेल नहीं होता। पूरे संदेश में भेजने वाले, प्राप्तकर्ताओं, विषय और तकनीकी विवरण वाले हेडर शामिल होते हैं। इसके अलावा संदेश का टेक्स्ट, जो अक्सर सादे टेक्स्ट और HTML दोनों रूपों में होता है, MIME हिस्सों के बीच की विभाजक लाइनें और हस्ताक्षर में लोगो जैसी एम्बेड की गई तस्वीरें भी होती हैं। इनका आकार कितना होगा, यह आपके ईमेल प्रोग्राम, आपके टेक्स्ट और आपके प्राप्तकर्ताओं पर निर्भर करता है।

अतिरिक्त बाइट के लिए कौन-सा मान दर्ज करें

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

तुलना में सीमा का पालन होने के बावजूद ईमेल वापस लौट आए तो

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

कैलकुलेटर केवल आपके चुने हुए संख्यात्मक मान की तुलना करता है। यह कुछ भेजता नहीं, ईमेल पहुँचने का परीक्षण नहीं करता और न ही फ़ाइल फ़ॉर्मैट या सुरक्षा नियमों की जाँच करता है। न्यूज़लेटर के प्रदर्शन की सीमाएँ भी होती हैं: कुछ मेलबॉक्स लंबे HTML ईमेल को केवल छोटा करके दिखाते हैं। यह अटैचमेंट के आकार से अलग विषय है और इसकी गणना भी यहाँ नहीं की जाती।

आकार बहुत बड़ा है: तैयार PDF के साथ आगे क्या करें

यदि अनुमान सीमा से अधिक है, तो आपके पास दो विकल्प हैं: फ़ाइल के बाइट कम करें या अटैचमेंट के अलावा कोई दूसरा तरीका चुनें। यदि प्राप्तकर्ता ने स्पष्ट रूप से अटैचमेंट माँगा है, तो इन चरणों का पालन करें:

  1. भेजने से पहले PDF कंप्रेस करें या, यदि आपको कोई निश्चित सीमा पता है, तो आकार सीमा के अनुरूप PDF का आकार घटाएँ। फ़ाइल का आकार कितना घटेगा, यह उसकी सामग्री पर निर्भर करता है। हर स्थिति में लक्ष्य आकार पाना संभव नहीं होता।
  2. परिणाम खोलें और जाँचें कि दस्तावेज़ अभी भी आसानी से पढ़ा जा सकता है या नहीं।
  3. डाउनलोड की गई फ़ाइल का आकार यहाँ दोबारा दर्ज करें। तैयार फ़ाइल का आकार मायने रखता है, अपेक्षित आकार की बचत नहीं।
  4. यदि अनुमान सीमा के भीतर है, तो ईमेल भेजें। यदि नहीं है, तो प्राप्तकर्ता से किसी दूसरे तरीके के बारे में बात करें।

किसी क्लाउड या फ़ाइल सेवा का साझा लिंक एक विकल्प हो सकता है, यदि प्राप्तकर्ता लिंक स्वीकार करता हो और पहुँच की अनुमतियाँ तथा डेटा गोपनीयता आपके दस्तावेज़ के लिए उपयुक्त हों। सेवा आप स्वयं चुनते हैं। यह कैलकुलेटर केवल दर्ज की गई संख्याओं के साथ काम करता है और फ़ाइलें न सहेजता है, न भेजता है। वहीं, ZIP आर्काइव छोटी PDF का भरोसेमंद विकल्प नहीं है: इससे PDF का आकार घटना ज़रूरी नहीं है, और संभव है कि विशेष रूप से PDF फ़ाइलें माँगने वाला व्यक्ति आर्काइव स्वीकार न करे।

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

गोपनीयता प्राथमिकताएँ

चुनें कि वैकल्पिक उपयोग विश्लेषण और विज्ञापन की अनुमति देनी है या नहीं। इस अप्रकाशित पूर्वावलोकन में अनुमति देने पर भी दोनों बंद रहेंगे। दस्तावेज़ टूल दोनों स्थितियों में काम करेंगे। आप पेज के निचले हिस्से से अपनी पसंद कभी भी बदल सकते हैं।

ज़रूरी सेटिंग

ज़रूरी

आपकी पसंद और रंग थीम इसी ब्राउज़र में सहेजी जाती हैं। दस्तावेज़ टूल वैकल्पिक सेवाओं के बिना भी उपलब्ध हैं।

निष्क्रिय

उपयोग का वैकल्पिक मापन। अभी निष्क्रिय है: अनुमति देने से आपकी पसंद सहेजी जाती है, लेकिन इस पूर्वावलोकन में कोई विश्लेषण सेवा चालू नहीं होती।

निष्क्रिय

वैकल्पिक विज्ञापन। अभी निष्क्रिय हैं: अनुमति देने से आपकी पसंद सहेजी जाती है, लेकिन इस पूर्वावलोकन में कोई विज्ञापन सेवा चालू नहीं होती।

वैकल्पिक उपयोग विश्लेषण और विज्ञापन बंद हैं।