मुफ़्त PDF मर्ज ऑनलाइन
कई PDF फ़ाइलों को एक में जोड़ें। पेज को फिर से क्रमबद्ध करें, फ़ाइलें हटाएं और तुरंत मर्ज करें। आपकी फ़ाइलें कभी आपके डिवाइस से बाहर नहीं जातीं।
PDF समर्थित · प्रत्येक 50 MB तक
यह कैसे काम करता है
- PDF अपलोड करें: मर्ज करने के लिए कई PDF फ़ाइलें छोड़ें या चुनें।
- व्यवस्थित करें: पेज को फिर से क्रमबद्ध करने के लिए ऊपर/नीचे बटन का उपयोग करें। अनचाही फ़ाइलें हटाएं।
- मर्ज करें: सभी फ़ाइलों को एक में जोड़ने के लिए "PDF मर्ज करें" पर क्लिक करें। प्रोसेसिंग तुरंत आपके ब्राउज़र में होती है।
PDF क्यों मर्ज करें?
PDF मर्ज करना दस्तावेज़ों को व्यवस्थित करने, कई स्रोतों से रिपोर्ट बनाने, सबमिशन तैयार करने या फ़ाइल बिखराव कम करने के लिए ज़रूरी है। कई अटैचमेंट भेजने या जटिल फ़ाइल संरचनाएं बनाने के बजाय, सब कुछ एक आसानी से साझा होने वाली PDF में जोड़ें। अनुबंध, प्रस्तुतियाँ, चालान और दस्तावेज़ीकरण के लिए बिल्कुल सही।
विशेषताएं
- असीमित फ़ाइलें: जितनी ज़रूरत हो उतनी PDF मर्ज करें।
- पेज फिर से क्रमबद्ध करें: मर्ज करने से पहले फ़ाइलों को किसी भी क्रम में व्यवस्थित करें।
- गोपनीयता: सारी प्रोसेसिंग आपके ब्राउज़र में स्थानीय रूप से होती है। फ़ाइलें किसी भी सर्वर पर अपलोड नहीं होतीं।
- तेज़: बिना इंतज़ार या कतार के तुरंत मर्जिंग।
अक्सर पूछे जाने वाले सवाल
क्या मैं अपलोड करने के बाद फ़ाइलें फिर से क्रमबद्ध कर सकता हूँ?
हाँ। हर फ़ाइल क्रम को समायोजित करने के लिए ऊपर/नीचे बटन दिखाती है। फ़ाइलें सूची में दिखाई देने वाले क्रम में मर्ज की जाती हैं।
फ़ाइल आकार की सीमा क्या है?
प्रत्येक PDF 50 MB तक हो सकती है। कुल मर्ज की गई फ़ाइल का आकार आपके ब्राउज़र की उपलब्ध मेमोरी पर निर्भर करता है, लेकिन आमतौर पर आप कई सौ MB की कुल फ़ाइलें मर्ज कर सकते हैं।
क्या मेरी PDF सर्वर पर अपलोड होती हैं?
नहीं। सारी मर्जिंग आपके ब्राउज़र में pdf-lib का उपयोग करके स्थानीय रूप से होती है। आपकी PDF कभी आपके डिवाइस से बाहर नहीं जातीं, जो पूर्ण गोपनीयता और सुरक्षा सुनिश्चित करता है।
क्या मैं मोबाइल पर PDF मर्ज कर सकता हूँ?
हाँ। यह टूल डेस्कटॉप, टैबलेट और मोबाइल ब्राउज़र पर काम करता है। बस फ़ाइलें चुनने और मर्ज करने के लिए टैप करें।
अगर PDF ख़राब हो तो क्या होगा?
टूल ख़राब फ़ाइलों के लिए एक त्रुटि दिखाएगा। अपने स्रोत से PDF को फिर से एक्सपोर्ट करने का प्रयास करें, या पहले किसी ऑनलाइन PDF रिपेयर टूल का उपयोग करें।
PDF और मर्ज ऑपरेशन का संक्षिप्त इतिहास
Adobe ने 1993 में Portable Document Format की घोषणा की और इसे कागज़ का डिजिटल विस्तार बताया: एक छपा हुआ पन्ना एक कंप्यूटर से दूसरे कंप्यूटर तक भेजने का तरीका, जिसमें पाने वाले को न तो वही फ़ॉन्ट लगाने हों, न वही ऑपरेटिंग सिस्टम, और न ही वही ऐप्लिकेशन जो उस पन्ने को बनाने वाला था। पहला संस्करण 15 जून को Acrobat 1.0 के साथ आया, रीडर की कीमत $695 और distiller की $2,500 रखी गई थी। अपनाव धीमा रहा जब तक Adobe ने 1994 में रीडर मुफ़्त नहीं किया और अमेरिकी आयकर विभाग (IRS) ने 1990 के दशक के आख़िर में भरने-योग्य कर फ़ॉर्म के लिए PDF को मानक नहीं बना दिया, इसी के साथ PDF दुनिया भर के सरकारी काम-काज में दाख़िल हुआ।
2008 तक स्पेसिफ़िकेशन इतना स्थिर हो चुका था कि Adobe ने उसे अंतर्राष्ट्रीय मानकीकरण संगठन (ISO) को सौंप दिया, जिसने उसी जुलाई में उसे ISO 32000-1 के रूप में प्रकाशित किया। मौजूदा संस्करण ISO 32000-2:2020 है, और हर गंभीर PDF टूल आज इसी मानक के अनुरूप काम करता है। इस पूरे इतिहास में मर्जिंग सबसे ज़्यादा इस्तेमाल होने वाली PDF प्रक्रियाओं में से एक रही है, कुल उपयोगकर्ता संख्या के हिसाब से केवल «देखो» और «प्रिंट» करो ही उससे आगे हैं। AIIM के 2021 के औद्योगिक सर्वे ने अनुमान लगाया कि एक औसत ज्ञान-कर्मचारी हर हफ़्ते दो से पाँच PDF मर्ज करता है, मध्यक ऑपरेशन में तीन से सात स्रोत फ़ाइलें होती हैं।
मर्जिंग ख़ुद PDF से पुरानी है। PostScript फ़ाइलों को 1989 में ही शेल पाइप से जोड़ा जा रहा था, कभी-कभी सचमुच एक फ़ाइल को दूसरी के पीछे जोड़कर और पेज मार्कर हाथ से नई संख्या में लिखकर। PDF ने इस काम को एक साथ आसान भी बनाया (क्योंकि फ़ाइल फ़ॉर्मैट क्रॉस-रेफ़रेंस तालिका से रैंडम-ऐक्सेस है) और मुश्किल भी (क्योंकि पन्ने की सामग्री एक रेखीय धारा में नहीं रहती)। हर आधुनिक PDF मर्जर, डेस्कटॉप Acrobat से लेकर इस ब्राउज़र टूल तक, एक ही नीचे के सवाल को हल कर रहा है: कई पेज ट्री लो और एक संयुक्त पेज ट्री बनाओ जो मूल कंटेंट ऑब्जेक्ट्स की ओर इशारा करे, और साथ ही पन्ने को उसके फ़ॉन्ट, छवियों और संसाधनों से जोड़ने वाली कोई भी अप्रत्यक्ष संदर्भ रेखा न टूटे।
फ़ाइल के भीतर «मर्ज» असल में क्या करता है
PDF कोई एकल दस्तावेज़ नहीं है; वह एक पेड़ है। जड़ catalog है, जो pages tree पर इशारा करता है, और उसकी पत्तियाँ अलग-अलग पेज ऑब्जेक्ट होती हैं। हर पेज ऑब्जेक्ट संदर्भ रखता है, संसाधन ख़ुद नहीं: उस पन्ने में काम आने वाले फ़ॉन्ट फ़ाइल बॉडी में अलग indirect ऑब्जेक्ट के रूप में रहते हैं, ऐसे ही छवियाँ, form XObject, ग्राफ़िक्स-स्टेट डिक्शनरी और पैटर्न भी। पन्ने का resources डिक्शनरी (/F1, /Im2, /GS0 जैसे) छोटे नामों को इन indirect ऑब्जेक्ट नंबरों से जोड़ता है। यही अप्रत्यक्षता है जिसकी वजह से मूल पन्नों की सामग्री को बदले बिना मर्जिंग संभव होती है: आप एक नया जड़ pages ऑब्जेक्ट बना सकते हैं जो कई स्रोत दस्तावेज़ों से ली गई पत्तियों की ओर इशारा करे।
सही मर्ज कोई बाइनरी जोड़ नहीं है। लाइब्रेरी हर स्रोत फ़ाइल की क्रॉस-रेफ़रेंस तालिका पढ़ती है, हर indirect ऑब्जेक्ट को मेमरी में पार्स करती है, फिर हर माँगे गए पन्ने के लिए संसाधनों के ग्राफ़ पर चलकर ट्रांज़िटिवली संदर्भित हर ऑब्जेक्ट को आउटपुट में नक़ल करती है। नक़ल हुए ऑब्जेक्ट गंतव्य की नंबरिंग-स्पेस में नए ऑब्जेक्ट नंबर पाते हैं, और उनके भीतर के हर संदर्भ को उसी हिसाब से दोबारा लिखा जाता है। आख़िर में एक नया pages tree बनता है जिसके बच्चे आपकी माँगी हुई क्रम में नक़ल हुई पेज पत्तियों की ओर इशारा करते हैं, और नई क्रॉस-रेफ़रेंस तालिका लिखी जाती है। स्रोत की कोई सामग्री decompress, re-encode या rasterize नहीं की जाती। स्रोत पन्नों के पाठ, छवियाँ और वेक्टर ग्राफ़िक्स ज्यों के त्यों आउटपुट में लिखे जाते हैं, इसी वजह से मर्जिंग lossless है और मर्ज की हुई फ़ाइल का आकार लगभग सभी इनपुट के जोड़ के बराबर होता है।
वे असली कार्य-प्रवाह जो मर्जिंग को चलाते हैं
- क़रार और क़ानूनी दाख़िलें। हस्ताक्षर हुआ क़रार शायद ही कभी एक ही दस्तावेज़ होता है। मास्टर अग्रीमेंट, अनुसूचियाँ, हस्ताक्षर पन्ने और अनुलग्नक सब एक साथ भेजने ज़रूरी होते हैं। अदालत के ई-फ़ाइलिंग सिस्टम, जिनमें अमेरिकी संघीय अदालतों का CM/ECF भी शामिल है, साक्ष्य के साथ प्रस्तावों के लिए स्पष्ट रूप से संयुक्त-PDF दाख़िलें माँगते हैं।
- व्यय रिपोर्ट और प्रतिपूर्ति। Concur, Expensify और अधिकतर एंटरप्राइज़ प्रतिपूर्ति सिस्टम हर दावे पर एक ही PDF लेते हैं। कर्मचारी रसीदें स्कैन या डाउनलोड करते हैं, उन्हें मर्ज करते हैं और अपलोड करते हैं। मर्जिंग हर महीने के व्यय-चक्र की आम लेसन है।
- लेटरहेड और कवर पन्ने। फ़ोटोग्राफ़र, सलाहकार और डिज़ाइनर एक-पन्ने का PDF लेटरहेड रखते हैं जिसे वे हर डिलीवरी से पहले जोड़ देते हैं। यह कला-कृति को दोबारा rasterize किए बिना एक जैसा ब्रांडिंग लगाने का सबसे सस्ता तरीक़ा है।
- पाठ्यक्रम सामग्री और परीक्षा प्रश्नपत्र। विश्वविद्यालय हर हफ़्ते की रीडिंग के संयुक्त PDF बाँटते हैं। परीक्षा बोर्ड प्रश्न-पुस्तिकाओं को उत्तर-कुंजी के साथ मिलाकर भेजते हैं। छात्र होमवर्क के पोर्टफ़ोलियो जोड़ते हैं। यह कुल मात्रा में सबसे बड़ा मर्ज उपयोग है, और सेमेस्टर-अंत समय-सीमा वाले हफ़्तों में अकादमिक भार चरम पर रहता है।
- सरकारी और आव्रजन दाख़िलें। USCIS, ब्रिटेन का Home Office और यूरोप के अधिकतर आव्रजन प्राधिकरण साक्ष्य के एक-PDF बंडल माँगते हैं। एक विशिष्ट नागरिकता आवेदन में 20 से 80 अलग-अलग स्कैन किए दस्तावेज़, हर एक अलग स्रोत फ़ॉर्मैट में, एक ही दाख़िल PDF में जोड़े जा सकते हैं।
- फ़ोटोग्राफ़ी और पोर्टफ़ोलियो सबमिशन। गैलरियाँ, एजेंसियाँ और कला-स्कूल आवेदन अक्सर एक संयुक्त PDF माँगते हैं, अकसर अधिकतम फ़ाइल आकार के साथ। मर्ज के बाद आमतौर पर एक compression पास होता है ताकि वह सीमा में आ जाए।
आम चूकें और उन्हें कैसे टालें
- फ़ॉर्म फ़ील्ड मरे हो जाते हैं। इंटरैक्टिव फ़ॉर्म डिक्शनरी दस्तावेज़ स्तर पर रहती है, अलग-अलग पन्नों पर नहीं। मर्जिंग फ़ॉर्म विजेट्स के दृश्य हिस्से (आयत, लेबल, appearance stream) तो नक़ल कर लेती है, पर वे field definitions नहीं जो उन्हें इंटरैक्टिव बनाती हैं। मर्ज हुआ फ़ॉर्म देखने में सही लगता है पर इनपुट नहीं लेता। हल: पहले हर फ़ॉर्म को मुफ़्त ऑनलाइन PDF फ़्लैटनिंग टूल से flatten करें, जो विजेट को साधारण पन्ने की सामग्री में बदल देता है, फिर मर्ज करें।
- बुकमार्क ग़ायब हो जाते हैं। Outline tree (Acrobat के साइड-रेल में दिखने वाला सूची-पत्र) दस्तावेज़ स्तर की संरचना है। कई स्रोत दस्तावेज़ों के outline को एक सुसंगत outline में मिलाने का कोई सामान्य एल्गोरिथ्म नहीं है, इसलिए अधिकतर ब्राउज़र-केवल मर्जर, इस वाले समेत, उन्हें त्याग देते हैं। अगर बुकमार्क ज़रूरी हैं, तो पहले मर्ज करें और फिर डेस्कटॉप एडिटर में outline हाथ से दोबारा बनाएँ।
- एन्क्रिप्ट किए हुए PDF लोड नहीं हो पाते। जब तक पासवर्ड न दिया जाए, खुले-पासवर्ड वाले PDF को पार्स नहीं किया जा सकता। यह टूल एन्क्रिप्टेड इनपुट का समर्थन नहीं करता। प्रक्रिया: पहले मुफ़्त PDF अनलॉक ऑनलाइन टूल से सुरक्षा हटाएँ, फिर अनलॉक की हुई प्रतियाँ मर्ज करें।
- हस्ताक्षर टूट जाते हैं। PDF पर डिजिटल हस्ताक्षर फ़ाइल के एक नियत बाइट-रेंज का क्रिप्टोग्राफ़िक हैश है। फ़ाइल में किसी भी तरह का बदलाव, जिसमें दूसरों से मर्ज भी शामिल है, हस्ताक्षर को अमान्य कर देता है। मर्ज हुआ आउटपुट तब भी मान्य PDF रहता है, पर «हस्ताक्षर मान्य» «हस्ताक्षर अमान्य» बन जाता है। क्रिप्टोग्राफ़ी की दृष्टि से यह सही व्यवहार है, पर शायद ही वह जो आप चाहते हैं। हल: हस्ताक्षरित PDF अलग फ़ाइलों के रूप में रखें; हस्ताक्षरित प्रति बरक़रार रहनी चाहिए।
- फ़ॉन्ट सबसेट दोहरे हो जाते हैं। जब वही फ़ॉन्ट दो स्रोत दस्तावेज़ों में आता है, तो आम तौर पर उसे दो थोड़े-थोड़े अलग subset के तौर पर embed किया जाता है। मर्जर के पास तुल्यता पहचानने का कोई सामान्य उपाय नहीं है, इसलिए आउटपुट दोनों प्रतियाँ ढोता है। नतीजतन मर्ज हुई फ़ाइल इनपुट के सीधे जोड़ से थोड़ी बड़ी होती है। मर्ज आउटपुट को मुफ्त ऑनलाइन PDF कम्प्रेस करें टूल से गुज़ारने पर अधिकांश अतिरिक्त भार वापस मिल जाता है।
ब्राउज़र-केवल बनाम क्लाउड मर्जिंग
इस टूल और Google के सर्च नतीजों में छाए हुए क्लाउड PDF मर्जरों के बीच सबसे बड़ा कार्यात्मक फ़र्क़ यह है कि पार्सिंग कहाँ होती है। Smallpdf, ILovePDF, PDF24 का वेब ऐप, Sejda का मुफ़्त स्तर और Adobe के ऑनलाइन टूल सब आपके स्रोत फ़ाइलें अपने सर्वरों पर अपलोड करते हैं, वहाँ मर्ज करते हैं, और मर्ज हुई फ़ाइल आपको डाउनलोड के तौर पर वापस देते हैं। उनकी प्राइवेसी नीति कहती है कि अपलोड हुई फ़ाइलें कुछ घंटों में हटा दी जाती हैं। फिर भी फ़ाइलें ऑपरेटर के नेटवर्क से होकर गुज़रती हैं, प्रोसेसिंग की खिड़की भर उनकी डिस्क पर रहती हैं, और जो भी log ऑपरेटर दुरुपयोग पकड़ने के लिए रखता है उसमें दर्ज होती हैं।
यह टूल वैसा नहीं करता। आपकी PDF फ़ाइलें मानक File API से ब्राउज़र टैब में पढ़ी जाती हैं, उसी टैब में pdf-lib लाइब्रेरी द्वारा पार्स की जाती हैं, और मानक डाउनलोड API से आपकी डिस्क पर वापस लिखी जाती हैं। मर्जिंग के दौरान केवल इतना ही नेटवर्क ट्रैफ़िक होता है: पन्ना पहली बार खुलने पर pdf-lib का एक बार CDN से लोड होना। आप जाँच सकते हैं: ब्राउज़र के डेवलपर टूल का Network टैब खोलें, एक मर्ज चलाएँ, और देखें कि कोई भी ऐसी रिक्वेस्ट नहीं चलती जो आपकी फ़ाइल का कंटेंट ले जाए। जो भी गोपनीय हो (HIPAA, GDPR, attorney-client विशेषाधिकार, गोपनीयता समझौते की बाध्यताएँ) उसे ब्राउज़र में ही मर्ज करना सबसे अच्छा है। जो कुछ कई-सौ मेगाबाइट से ज़्यादा हो, जिसके बाद OCR चाहिए हो, या जिसमें भूमिका-आधारित ऐक्सेस ज़रूरी हो, उसके लिए सर्वर-तरफ़ा कोई टूल चुनें जिसकी डेटा-शर्तें आप ख़ुद पढ़ चुके हों।
सुगम्यता पर एक टिप्पणी
PDF सुगम्यता ISO 14289 (PDF/UA-1) और W3C के «PDF Techniques for WCAG 2.0» से नियंत्रित होती है। एक सही तरह से tag किए गए PDF में एक संरचना-वृक्ष होता है जो तार्किक पठन-क्रम, शीर्षक, सूचियाँ, तालिका कोशिकाएँ और चित्रों का वैकल्पिक पाठ बताता है। JAWS, NVDA और VoiceOver जैसे स्क्रीन रीडर इस वृक्ष का इस्तेमाल करके दस्तावेज़ को दृष्टि-क्रम के बजाय एक समझदार क्रम में पेश करते हैं, क्योंकि दृष्टि-क्रम अकसर कॉलमों या साइडबार वाला होता है। संरचना-वृक्ष दस्तावेज़ स्तर का ऑब्जेक्ट है, इसलिए इस टूल में दो tag किए हुए PDF मर्ज करने पर बिना tag वाली आउटपुट मिलती है। निजी अभिलेखों और प्रतिपूर्ति बंडलों के लिए यह ठीक है। दृष्टि-बाधित पाठकों के सार्वजनिक उपयोग के लिए बने दस्तावेज़ों के लिए, मर्ज आउटपुट को Adobe Acrobat के «Make Accessible» action wizard से सुधारना होगा, या उन सपाट स्कैन वाले PDF से शुरू करना होगा जिनमें खोने को कोई सुगम्यता-मेटाडेटा है ही नहीं।
और अकसर पूछे जाने वाले प्रश्न
क्या मैं एक बार में 50 MB से ज़्यादा PDF मर्ज कर सकता हूँ?
हर फ़ाइल 50 MB तक हो सकती है, और कुल मर्ज आकार की व्यावहारिक सीमा डेस्कटॉप ब्राउज़र पर लगभग 300 MB और मोबाइल पर लगभग 100 MB है। दोनों संख्याएँ PDF फ़ॉर्मैट की वजह से नहीं, बल्कि ब्राउज़र मेमरी की देन हैं। ISO 32000-2 फ़ाइलों को 2^64 बाइट तक की अनुमति देता है, सो PDF रुकावट नहीं है। रुकावट JavaScript heap है, जिसे अधिकतर ब्राउज़र हर टैब पर 2 से 4 GB तक रखते हैं। अगर आपका संयुक्त इनपुट इन संख्याओं के निकट या उससे ऊपर है, Adobe Acrobat या Apple Preview जैसा डेस्कटॉप टूल इसे ज़्यादा भरोसे से करेगा।
मेरी मर्ज की हुई फ़ाइल इनपुट के जोड़ से थोड़ी बड़ी क्यों है?
अकसर मर्ज फ़ाइल मूलतः जोड़ ही होती है, कुछ प्रतिशत आगे-पीछे। यह अतिरिक्त भार आता है: दोहराए हुए फ़ॉन्ट सबसेट (वही फ़ॉन्ट दो स्रोत दस्तावेज़ों ने अलग-अलग embed किया, सो आउटपुट में दो बार दिखता है), दोहराए छवि-संसाधन जिन्हें मर्जर तुल्य नहीं पहचान सका, और संयुक्त ऑब्जेक्ट गिनती को ढकने वाली नई क्रॉस-रेफ़रेंस तालिका। मर्ज आउटपुट को PDF Compress टूल से गुज़ारने पर इस अतिरिक्त भार का अधिकांश हिस्सा लौट आता है।
क्या मैं अलग-अलग पेज आकार वाले PDF मर्ज कर सकता हूँ?
हाँ। PDF का हर पन्ना अपना ख़ुद का media box ले चलता है, यानी वह आयत जो उसकी दिखाई देने वाली परिधि तय करता है। मर्ज हुए PDF में आकारों का कोई भी मिश्रण (A4, US Letter, A3, मनचाहे आयाम) हो सकता है, और अधिकतर रीडर हर पन्ने को उसके मूल आकार में दिखाते हैं। मर्ज फ़ाइल ख़ुद कोई «विजेता» आकार नहीं चुनती। अगर आउटपुट में हर पन्ना एक ही आकार का चाहिए, तो वह अलग ऑपरेशन है (रीसाइज़िंग), जो मर्जर नहीं करता।
क्या मर्जिंग मेरा मेटाडेटा हटा देगी?
दस्तावेज़ info डिक्शनरी (शीर्षक, लेखक, विषय, कीवर्ड, producer) पहले स्रोत दस्तावेज़ से ली जाती है। बाद के स्रोतों का कोई भी मेटाडेटा त्याग दिया जाता है। XMP मेटाडेटा धारा, जहाँ आधुनिक PDF सघन संरचित मेटाडेटा रखते हैं, pdf-lib नए सिरे से बनाती है। यदि मर्ज के पार ख़ास मेटाडेटा बनाए रखना ज़रूरी है, उसे पहले स्रोत दस्तावेज़ में जान-बूझकर सेट करें, या मर्ज के बाद डेस्कटॉप एडिटर से लागू करें।
क्या फ़ाइलें छोड़ने का क्रम मायने रखता है?
हाँ। फ़ाइलें उसी क्रम में मर्ज होती हैं जिसमें वे सूची में दिखती हैं। «Merge PDFs» पर क्लिक करने से पहले आप हर फ़ाइल पंक्ति के ऊपर/नीचे बटनों से क्रम बदल सकते हैं। पहली फ़ाइल आउटपुट के पहले पन्नों में बदलती है, दूसरी उसके बाद, और इसी क्रम में। मेटाडेटा भी पहली फ़ाइल से ली जाती है, इसलिए जिस दस्तावेज़ का शीर्षक और लेखक रखना है, उसे सबसे ऊपर रखें।