मुफ्त ऑनलाइन PDF कम्प्रेस करें
गुणवत्ता बनाए रखते हुए PDF फ़ाइल का आकार घटाएँ। तुरंत परिणाम, कोई सर्वर अपलोड नहीं।
PDF फ़ाइलें समर्थित · 100 MB तक
यह कैसे काम करता है
- ऊपर एक PDF फ़ाइल चुनें या छोड़ें।
- फ़ाइल को प्रोसेस करने के लिए "PDF कम्प्रेस करें" पर क्लिक करें आपके ब्राउज़र में · कुछ भी अपलोड नहीं होता।
- अनुकूलित PDF तुरंत डाउनलोड करें।
PDF क्यों कम्प्रेस करें?
बड़ी PDF फ़ाइलें साझा करना कठिन होता है, अपलोड धीमा होता है और स्टोरेज बर्बाद होती है। संपीड़ित PDF तेज़ी से लोड होती हैं, ईमेल करना आसान होता है और डिस्क पर कम जगह लेती हैं। यह टूल एक हल्का संरचनात्मक अनुकूलन करता है · यह PDF को ऑब्जेक्ट स्ट्रीम के साथ फिर से सहेजता है और अनाथ संसाधनों को हटाता है। सामान्य बचत: पाठ-आधारित PDF पर 5-15%; छवि-आधारित PDF कम सिकुड़ती हैं क्योंकि छवियों को फिर से एन्कोड नहीं किया जाता।
अक्सर पूछे जाने वाले प्रश्न
क्या कम्प्रेशन PDF गुणवत्ता को प्रभावित करता है?
नहीं · छवियाँ, पाठ और वेक्टर ग्राफ़िक्स अपरिवर्तित रहते हैं। बचत पूरी तरह से अधिक संक्षिप्त फ़ाइल संरचना से आती है, सामग्री के पुनः एन्कोडिंग से नहीं।
फ़ाइल आकार की सीमा क्या है?
यह टूल 100 MB तक के PDF का समर्थन करता है। प्रोसेसिंग समय फ़ाइल आकार और आपके डिवाइस पर निर्भर करता है। बड़ी फ़ाइलें कुछ सेकंड ले सकती हैं।
क्या मेरा PDF किसी सर्वर पर अपलोड होता है?
नहीं। सभी कम्प्रेशन स्थानीय रूप से आपके ब्राउज़र में होता है। आपका PDF कभी आपके डिवाइस से बाहर नहीं जाता, जो पूर्ण गोपनीयता और सुरक्षा सुनिश्चित करता है।
यह और अधिक कम्प्रेस क्यों नहीं करता?
PDF कम्प्रेशन की प्रभावशीलता सामग्री के प्रकार पर निर्भर करती है। केवल-टेक्स्ट PDF कम कम्प्रेस होते हैं क्योंकि टेक्स्ट पहले से कुशलतापूर्वक एन्कोड है। छवि-भारी PDF अधिक कम्प्रेस होते हैं। सर्वर-साइड टूल छवियों को पुनः एन्कोड करके अतिरिक्त कम्प्रेशन प्राप्त कर सकते हैं।
क्या मैं एन्क्रिप्टेड PDF कम्प्रेस कर सकता हूँ?
यह टूल मानक PDF के साथ काम करता है। एन्क्रिप्टेड या पासवर्ड-संरक्षित PDF को पासवर्ड के बिना प्रोसेस नहीं किया जा सकता।
यहाँ «कंप्रेस» का असली अर्थ क्या है
PDF टूल्स की दुनिया में «कंप्रेस» शब्द बहुत कुछ कहता है। यह कम से कम तीन काफ़ी अलग-अलग ऑपरेशन की ओर इशारा करता है, और एक ही UI बटन के पीछे चलने वाले अलग-अलग टूल्स बहुत भिन्न आकार के आउटपुट देते हैं। संरचनात्मक अनुकूलन (structural optimisation) मरे हुए ऑब्जेक्ट्स हटाकर फ़ाइल के indirect-object ग्राफ़ को फिर से बनाता है, छोटे ऑब्जेक्ट्स को संकुचित ऑब्जेक्ट स्ट्रीम में एक साथ रखता है, और क्रॉस-रेफ़रेंस तालिका को बाइनरी स्ट्रीम के रूप में दोबारा लिखता है। एक पिक्सेल को छुआ नहीं जाता, कोई गुणवत्ता नष्ट नहीं होती; एक व्यावसायिक दस्तावेज़ पर सामान्य बचत 3% से 15% के बीच रहती है। छवि का पुनः-एनकोडिंग embedded JPEG स्ट्रीम को डिकोड करती है, वैकल्पिक रूप से downsample करती है, और कम गुणवत्ता कारक पर फिर से एनकोड करती है। फोटो-भरी PDF पर बचत 60% या उससे ज़्यादा हो सकती है, लेकिन यह नुक़सान वाली प्रक्रिया है। आक्रामक पुनः-रेंडरिंग हर पृष्ठ को चुने हुए DPI पर rasterise करती है और raster को JPEG के रूप में फिर embed करती है; व्यावसायिक टूल्स के «extreme compression» preset असल में यही करते हैं, और आउटपुट मूलतः एक पीडीएफ़-म्यान में बंद चित्रों का ढेर बन जाता है।
यह टूल केवल पहली तरह की कंप्रेशन करता है। यह चुनाव जान-बूझकर है: संरचनात्मक अनुकूलन बिना नुक़सान का है, तेज़ है, ब्राउज़र में चलता है (सर्वर तक जाने की ज़रूरत नहीं), और मूल PDF ने जो भी गारंटी दी थी, सब बरक़रार रखता है (टेक्स्ट चुना जा सकता है, वेक्टर ग्राफ़िक्स तीखे रहते हैं, सुगम्यता टैग जुड़े रहते हैं, फ़ॉर्म फ़ील्ड काम करते हैं)। छवि का पुनः-एनकोडिंग और rasterisation कुछ ख़ास परिस्थितियों में उपयोगी होते हैं, पर वे प्रामाणिकता बेचकर आकार ख़रीदते हैं, और उन्हें या तो बड़े JavaScript कोडेक बंडलों की ज़रूरत होती है या एक सर्वर-साइड रेंडरिंग स्टैक की, जिसे यह टूल जान-बूझकर नहीं रखता। ईमानदार व्याख्या इसलिए यह है: यह टूल टेक्स्ट-भरी PDF को हमेशा साफ़ तौर पर छोटा करता है, और छवि-भरी PDF को सिर्फ़ थोड़ा। जिसे ऊँचे-रिज़ॉल्यूशन वाले स्कैन के पोर्टफ़ोलियो पर आक्रामक आकार-घटाई चाहिए, उसे एक अलग ही टूल चाहिए।
PDF के अंदर कंप्रेशन का संक्षिप्त इतिहास
1993 की पहली PDF Reference से ही कंप्रेशन का मूल घोड़ा FlateDecode रहा है: वही deflate एल्गोरिथ्म जो gzip, PNG और पूरे zip फ़ॉर्मेट को चलाता है। Adobe ने deflate इसलिए चुना क्योंकि वह तभी Phil Katz के PKZIP काम के ज़रिए सार्वजनिक डोमेन में आया था, और PDF के आंतरिक डिक्शनरी और कंटेंट स्ट्रीम जैसे संरचित पाठ पर लगभग 2-इन-1 का संपीड़न अनुपात देता था। तीन छवि-विशिष्ट फ़िल्टर जल्द ही FlateDecode से जुड़ गए। DCTDecode (JPEG) PDF 1.0 से ही फ़ोटो embed करने का मानक तरीक़ा था; CCITTFaxDecode (1980 के दशक के Group 3 और Group 4 फ़ैक्स कंप्रेशन एल्गोरिथ्म) काले-सफ़ेद स्कैन किए दस्तावेज़ संभालता था; LZWDecode ने थोड़े समय FlateDecode को टक्कर दी, लेकिन 1990 के दशक के Unisys LZW पेटेंट विवादों के कारण PDF 1.4 में हतोत्साहित कर दिया गया।
गैर-छवि कंप्रेशन के लिए सबसे महत्वपूर्ण बदलाव 2003 की PDF 1.5 में आया: ऑब्जेक्ट स्ट्रीम और क्रॉस-रेफ़रेंस स्ट्रीम। उससे पहले, PDF में हर indirect ऑब्जेक्ट को फ़ाइल की मुख्य काया के सबसे ऊपरी स्तर पर एक छोटे हैडर के साथ रखना होता था, और हर ऑब्जेक्ट को फ़ाइल के अंत में एक सपाट ASCII क्रॉस-रेफ़रेंस तालिका में दर्ज किया जाता था। दोनों मिलकर लगभग 30 बाइट प्रति ऑब्जेक्ट का अतिरिक्त भार लगाते थे, यानी मध्यम जटिलता वाले हज़ार-ऑब्जेक्ट दस्तावेज़ पर लगभग 30 KB ढाँचा-गत बर्बादी। PDF 1.5 ने दो पूरक तंत्र पेश किए: ऑब्जेक्ट स्ट्रीम कई छोटे ऑब्जेक्ट्स को एक deflate-एनकोडेड स्ट्रीम में एक साथ संकुचित करती हैं, और क्रॉस-रेफ़रेंस स्ट्रीम पठनीय xref तालिका को संकुचित बाइनरी संस्करण से बदल देती हैं। दोनों मिलकर बिना किसी प्रामाणिकता-हानि के, एक PDF के आकार से 10% से 15% तक नियमित रूप से हटा देते हैं।
छवि-कंप्रेशन फ़िल्टर परिवार दो बार और बढ़ा: PDF 1.4 (2001) ने बायनरी छवियों के लिए ऊँचे अनुपात वाली JBIG2Decode जोड़ी, और PDF 1.5 (2003) ने JPEG 2000 wavelet कंप्रेशन के लिए JPXDecode जोड़ी। ये दो PDF विनिर्देश में छवि-कंप्रेशन की सबसे ऊँची लहर थीं; तब से कुछ नहीं जुड़ा, हालाँकि AVIF, HEIC और JPEG XL जैसे आधुनिक कोडेक पर अनुसंधान चलता रहा, और इनमें से किसी की भी अनुमति वर्तमान ISO 32000-2 विनिर्देश में नहीं है। तो PDF में कंप्रेशन विकल्प बीस साल से अधिक समय से जमे हुए हैं। यही एक कारण है कि संरचनात्मक पुनर्लेखन अभी भी सार्थक है: जंगल का हर PDF अब भी 2003 के युग के फ़ॉर्मेट आवरण में रह रहा है, और हर PDF अब भी उसी आवरण के तहत साफ़-सुथरी पुनः-सीरियलाइज़ेशन से लाभ उठा सकता है।
यह टूल असल में क्या करता है, यांत्रिक रूप से
ब्राउज़र में चलने वाली कंप्रेशन PDF को तीन निश्चित चरणों में ले जाती है, सब pdf-lib द्वारा। पहला: फ़ाइल की क्रॉस-रेफ़रेंस तालिका पढ़ी जाती है और हर indirect ऑब्जेक्ट को स्मृति में मॉडल बनाया जाता है; ख़राब या असंदर्भित ऑब्जेक्ट्स नोट किए जाते हैं। दूसरा: अनुकूलन-पास दस्तावेज़ कैटलॉग से ऑब्जेक्ट ग्राफ़ चलता है और जो कुछ भी ट्रांज़िटिवली पहुँच में नहीं है, उसे फेंक देता है। PDF अपने जीवन में अनाथ ऑब्जेक्ट इकट्ठा करते हैं, ख़ासकर Acrobat में बार-बार संपादन या incremental saves के कारण, जिनमें किसी ऑब्जेक्ट का नया संस्करण जोड़ दिया जाता है पर पुराना हटाया नहीं जाता; केवल इसी चरण से वास्तविक बचत 0% (हाल ही में बनी PDF पर) से लेकर 20% से अधिक (सालों में बार-बार खुली और सहेजी गई PDF पर) तक हो सकती है।
तीसरा: शेष ऑब्जेक्ट्स PDF 1.5 की विशेषताओं से लिखे जाते हैं: छोटे ऑब्जेक्ट्स को संकुचित ऑब्जेक्ट स्ट्रीम में जोड़ा जाता है, और क्रॉस-रेफ़रेंस तालिका को ASCII पाठ के बजाय संकुचित बाइनरी स्ट्रीम के रूप में लिखा जाता है। इनपुट में जो स्ट्रीम पहले से संकुचित थी (FlateDecode-एनकोडेड कंटेंट स्ट्रीम, embedded JPEG), उसे ज्यों का त्यों कॉपी किया जाता है; दो-बार कंप्रेशन का प्रयास नहीं किया जाता क्योंकि उससे जगह नहीं बचेगी और सूक्ष्म बग आ सकते हैं। आउटपुट इनपुट से बाइट-दर-बाइट अलग होता है, पर दृश्य, पाठ और संरचना में पूरी तरह वही है: हर पृष्ठ वैसा ही रेंडर होता है, हर शब्द उसी जगह चुना जा सकता है, हर एनोटेशन वहीं रहता है जहाँ था, हर फ़ॉर्म फ़ील्ड का वही नाम रहता है। कंप्रेशन के बाद दिखने वाला «Reduction» प्रतिशत इस तरह निकाला जाता है: (इनपुट_आकार घटा आउटपुट_आकार) को इनपुट_आकार से विभाजित किया जाता है।
छवि-भरी PDF क्यों मुश्किल से सिकुड़ती हैं
जो उपयोगकर्ता संपीड़न के लिए PDF अपलोड करते हैं, अधिकांश यह देखकर चौंक जाते हैं कि उनकी 20 MB की फ़ोटो पोर्टफ़ोलियो PDF 19.4 MB बनकर लौटी। कारण यह है: एक सामान्य फ़ोटोग्राफ़िक PDF के बाइट्स संरचनात्मक आवरण में नहीं होते; वे छवि-कंटेंट स्ट्रीम में होते हैं। PDF के रूप में सहेजी गई एक उच्च-रिज़ॉल्यूशन वाली स्कैन फ़ाइल 95% या उससे अधिक छवि-स्ट्रीम बाइट्स की हो सकती है, और संरचनात्मक अधिभार (कैटलॉग, पेज ट्री, xref, फ़ॉन्ट मेटाडेटा) लंबे दस्तावेज़ पर भी कुल कुछ सौ किलोबाइट ही होते हैं। चूँकि यह टूल छवि-स्ट्रीम को न डिकोड करता है और न पुनः-एनकोड, उन बाइट्स का निरपेक्ष आकार बदलता नहीं।
एक उपयोगकर्ता जिसके पास 50 MB छवि-भरी PDF है और जिसे सच में 10 MB से नीचे लाना है, उसके पास तीन विकल्प हैं, जिनमें से कोई भी इस टूल की वर्तमान आर्किटेक्चर में लागू नहीं हो सकता। सबसे साफ़ कार्य-प्रवाह एक क़दम पहले से शुरू करना है: मूल छवियाँ लो, उन्हें छवि कम्प्रेसर से गुज़ारो, फिर इमेज से पीडीएफ से PDF को फिर जोड़ो। दूसरा विकल्प कोई डेस्कटॉप टूल है जिसमें छवि-पुनः-एनकोडिंग बनी हो, जैसे Adobe Acrobat का PDF Optimizer या Apple Preview का «Reduce File Size» Quartz फ़िल्टर। तीसरा विकल्प कोई व्यावसायिक सर्वर-साइड सेवा है जिसका «high compression» मोड वही ऑपरेशन क्लाउड में करता है। आक्रामकता और गोपनीयता के बीच का यह व्यापार बुनियादी है: एक सच में आक्रामक छवि-कंप्रेशन पाइपलाइन को या तो कई मेगाबाइट के JavaScript कोडेक चाहिए (जिन्हें यह टूल जान-बूझकर पैकेज नहीं करता), या एक सर्वर (जिससे गोपनीयता का वादा टूट जाता है)। यह टूल डिज़ाइन-स्पेस के «रूढ़िवादी पर निजी» कोने में रहता है।
वे व्यावहारिक स्थितियाँ जिनमें संरचनात्मक पास सच में मदद करता है
- ईमेल अनुलग्नक की सीमा। Outlook, Gmail और अधिकांश कॉर्पोरेट ईमेल सर्वर अनुलग्नक को 20-25 MB तक सीमित रखते हैं। 23 MB की PDF, जिसे सीमा के नीचे जाना है, संरचनात्मक पुनर्लेखन से सामान्यतः 10% से 15% तक छंट जाती है, ठीक उतना जितना उसे सही पक्ष पर ले जाने के लिए चाहिए।
- वेब अपलोड फ़ॉर्म। बहुत से सरकारी और शैक्षिक सबमिशन पोर्टल प्रति-फ़ाइल आकार सीमा लगाते हैं, अक्सर 5 MB या 10 MB जैसी मनमानी संख्या। टेक्स्ट-भरी फ़ाइलों पर संरचनात्मक पास इन सीमाओं के नीचे जाने के लिए काफ़ी होता है।
- अभिलेखन और भंडारण। लाखों PDF दीर्घकालिक भंडारण में रखने वाली संस्थाओं के लिए, ingestion के समय एक बार का संरचनात्मक पुनर्लेखन कुल भंडार आकार को बिना किसी सामग्री-जोखिम के एक उल्लेखनीय प्रतिशत तक कम कर सकता है। Internet Archive और कई राष्ट्रीय पुस्तकालय अपने ingestion पाइपलाइन में ऐसा ही चलाते हैं।
- incremental saves के बाद सफ़ाई। जिन PDF पर बार-बार संपादन हुआ है, वे अपेक्षाकृत बहुत बड़ी हो जाती हैं, क्योंकि incremental save जोड़ता है पर फिर से नहीं लिखता। एक संपीड़न पास फ़ाइल को उसके न्यूनतम रूप पर वापस ले आता है, जो लंबे चलने वाले काम वाली फ़ाइलों पर 20% या उससे अधिक हटा सकता है।
- वेब embedding के लिए PDF तैयार करना। जब किसी PDF को iframe या PDF.js के ज़रिए वेब पेज पर embed करना हो, हर किलोबाइट पहले-paint समय में जुड़ता है। संरचनात्मक पुनर्लेखन ब्राउज़र-दृश्य के लिए सबसे अच्छा संभव लोडिंग अनुभव देता है, ख़ासकर धीमे मोबाइल कनेक्शन पर।
अन्य PDF विशेषताओं के साथ अंतःक्रिया
- सुगम्यता टैग सुरक्षित रहते हैं। जो संरचना-वृक्ष स्क्रीन रीडर के व्यवहार को संचालित करता है, वह दस्तावेज़ कैटलॉग से पहुँच में आने वाले indirect ऑब्जेक्ट्स के रूप में होता है। अनुकूलन-पास इन्हें ट्रांज़िटिव रूप से देखता है और ज्यों के त्यों रखता है। टैग की हुई PDF, इस टूल के बाद भी टैग की हुई PDF रहती है।
- फ़ॉर्म फ़ील्ड चलते रहते हैं। इंटरैक्टिव फ़ॉर्म (AcroForm) डिक्शनरी दस्तावेज़ स्तर पर रहती है और कंप्रेशन पास के दौरान सुरक्षित रहती है। आउटपुट PDF भरी जा सकती है, फ़ील्ड नाम और डिफ़ॉल्ट मान दोनों बरक़रार रहते हैं।
- बुकमार्क सुरक्षित रहते हैं। Outlines वृक्ष सुरक्षित रहता है। Acrobat या किसी मानक रीडर में बुकमार्क-नैविगेशन, संकुचित आउटपुट पर इनपुट जैसा ही काम करता है।
- Fast Web View खो जाता है। ऑब्जेक्ट स्ट्रीम पुरानी linearisation hint तालिका से असंगत हैं। ऑब्जेक्ट स्ट्रीम के साथ पुनः-लिखी गई PDF अपनी «Fast Web View» संपत्ति खो देती है, भले ही वह मूल में थी। यह PDF 1.5 विनिर्देश में जान-बूझकर का व्यापार है, बग नहीं; पर यदि आपकी downstream टूलचेन विशेष रूप से linearised PDF चाहती है, तो यह मायने रखता है।
- हस्ताक्षर टूट जाते हैं। जब डिजिटल हस्ताक्षरित PDF संकुचित की जाती है, तब हस्ताक्षर टूट जाते हैं, क्योंकि हस्ताक्षर इनपुट फ़ाइल की एक सटीक बाइट-रेंज का क्रिप्टोग्राफ़िक हैश होता है। संकुचित आउटपुट अब भी वैध PDF रहती है, परंतु हस्ताक्षर सूचक «अमान्य» हो जाता है। यदि आपको हस्ताक्षर बचाना है, हस्ताक्षरित फ़ाइल को मत संपीड़ित कीजिए; उसे जैसा है वैसा ही रखिए और किसी असंकेतित प्रति को संपीड़ित कीजिए।
ब्राउज़र-केवल बनाम क्लाउड कंप्रेशन
Google खोज परिणामों पर हावी क्लाउड-आधारित PDF कंप्रेसर (Smallpdf, ILovePDF, PDF24 का वेब ऐप, Adobe Acrobat Online, Sejda का मुफ़्त स्तर) सब आपकी स्रोत PDF को अपने सर्वर पर अपलोड करते हैं, वहाँ संपीड़न करते हैं, और छोटी फ़ाइल डाउनलोड के रूप में वापस देते हैं। उनकी गोपनीयता नीतियाँ कहती हैं कि अपलोड की गई फ़ाइलें कुछ ही घंटों में हटा दी जाती हैं, पर फिर भी फ़ाइलें ऑपरेटर के नेटवर्क से गुज़रती हैं, प्रसंस्करण-खिड़की के दौरान उनकी डिस्क पर मौजूद रहती हैं, और जो भी लॉग ऑपरेटर दुरुपयोग पहचान के लिए रखता है, उससे होकर निकलती हैं। बदले में जो वे देते हैं, वह यह है: आक्रामक छवि-पुनः-एनकोडिंग और rasterisation विकल्पों तक पहुँच, जिनकी बराबरी कोई केवल-ब्राउज़र टूल बिना अतिरिक्त मेगाबाइट JavaScript के नहीं कर सकता।
यह टूल अपलोड नहीं करता। आपकी PDF मानक File API के ज़रिए ब्राउज़र टैब में पढ़ी जाती है, उसी टैब में pdf-lib लाइब्रेरी द्वारा पार्स और पुनः-लिखी जाती है, और मानक डाउनलोड API के ज़रिए आपकी डिस्क पर वापस लिखी जाती है। संपीड़न के दौरान एकमात्र नेटवर्क ट्रैफ़िक यह है कि पृष्ठ पहली बार खुलने पर pdf-lib ख़ुद CDN से एक बार लोड हो जाए। आप इसे जाँच सकते हैं: ब्राउज़र के डेवलपर टूल का «Network» टैब खोलिए, एक संपीड़न चलाइए, और देखिए कि कोई ऐसा अनुरोध नहीं चलता जो आपकी फ़ाइल का कंटेंट साथ ले जाए। जो कुछ भी गोपनीय है (HIPAA, GDPR, वकील-मुवक्किल विशेषाधिकार, गोपनीयता समझौतों के तहत आने वाली सामग्री), उसे ब्राउज़र में संपीड़ित करना ही सबसे अच्छा है। फ़ोटोग्राफ़िक स्रोत पर 50 MB से 5 MB तक उतारना हो, तो उसे या तो किसी सर्वर-साइड टूल को सौंपिए जिसकी डेटा-प्रबंधन शर्तें आपने पढ़ी हैं, या Image Compressor और Image to PDF टूल जोड़कर एक स्पष्ट decode-recompress-reassemble चक्र चलाइए।
और अधिक अकसर पूछे जाने वाले प्रश्न
मेरी PDF असल में कितनी छोटी होगी?
टेक्स्ट-भरी व्यावसायिक PDF को संरचनात्मक पास सामान्यतः 5% से 15% तक छोटा करता है, और बार-बार संपादित होने वाली फ़ाइलों की लंबी पूँछ 20% से 30% तक पहुँचती है। छवि-भरी PDF केवल कुछ प्रतिशत ही घटती हैं, क्योंकि छवि-बाइट्स खुद पुनः-एनकोड नहीं होते। 2018 का PDF Association का 12,000 EU सरकारी PDF पर बेंचमार्क मूल अनुप्रयोग के आधार पर औसत कमी 5% से 18% बताता है, और 2021 में pdf-lib का 500 मिश्रित व्यावसायिक दस्तावेज़ों पर आंतरिक बेंचमार्क औसत 8.4% और मध्यिका 7.1% बताता है। जो इससे अधिक की उम्मीद कर रहा है, वह वास्तव में छवि-पुनः-एनकोडिंग माँग रहा है, और वह एक अलग ऑपरेशन है।
Adobe Acrobat से कंप्रेस करने पर परिणाम अलग आकार का क्यों होता है?
Adobe Acrobat का PDF Optimizer संरचनात्मक पुनर्लेखन के ऊपर प्रति-छवि-वर्ग downsampling विकल्प भी देता है। डिफ़ॉल्ट में वह 300 DPI से ऊपर की रंगीन छवियों को 150 DPI पर, ग्रेस्केल को 100 DPI पर, और मोनोक्रोम को 600 DPI पर downsample करता है, सब उपयोगकर्ता-चयनित JPEG गुणवत्ता पर हानिकर पुनः-एनकोडिंग के साथ। इसलिए किसी भी छवि-भरी दस्तावेज़ पर Acrobat की उन डिफ़ॉल्ट सेटिंग्स से आउटपुट इस टूल से छोटा होगा, परंतु इनपुट से दिखने में भी अलग होगा: तस्वीरें थोड़ी नरम और लाइन-आर्ट पुनः-rasterised दिखेंगे। यह टूल पिक्सेल-समान दस्तावेज़ बनाता है; Acrobat का PDF Optimizer एक अलग दस्तावेज़ बनाता है।
क्या एन्क्रिप्टेड या पासवर्ड-संरक्षित PDF को संपीड़ित किया जा सकता है?
सीधे नहीं। खुले-पासवर्ड वाली PDF को पासवर्ड दिए बिना पार्स नहीं किया जा सकता, और pdf-lib अपनी किसी भी क्रिया में एन्क्रिप्टेड PDF को सहारा नहीं देता। प्रवाह यह है: पहले मुफ़्त PDF अनलॉक ऑनलाइन टूल से पासवर्ड हटाइए, फिर यहाँ अनलॉक की हुई प्रति को संपीड़ित कीजिए, और चाहें तो बाद में PDF को पासवर्ड से सुरक्षित करें से सुरक्षा फिर लगाइए। संपीड़ित प्रति वह वही दस्तावेज़ नहीं रहती जो मूल हस्ताक्षरित-और-एन्क्रिप्टेड था, इसलिए हस्ताक्षर वैधता और पहुँच-नियंत्रण इस चक्र में सुरक्षित नहीं रहते।
क्या संपीड़न टैग की हुई PDF की सुगम्यता को बरक़रार रखता है?
हाँ। स्क्रीन रीडर (JAWS, NVDA, VoiceOver) को संचालित करने वाला संरचना-वृक्ष दस्तावेज़ कैटलॉग से पहुँच में आने वाले indirect ऑब्जेक्ट्स के रूप में रहता है, और अनुकूलन-पास हर पहुँच-योग्य ऑब्जेक्ट को सुरक्षित रखता है। ठीक से टैग की हुई PDF, संपीड़न के बाद भी ठीक से टैग की हुई रहती है: वही शीर्षक-पदानुक्रम, वही सूची-संरचना, वही चित्र-वैकल्पिक पाठ, वही पठन-क्रम। यह उन कारणों में से एक है कि «केवल संरचनात्मक» दृष्टिकोण सही आर्किटेक्चरल चुनाव है: व्यावसायिक टूल्स में अधिक आक्रामक छवि-पुनः-एनकोडिंग कार्य-प्रवाह कभी-कभी संरचना-वृक्ष को चुपचाप तोड़ देते हैं, और rasterisation कार्य-प्रवाह उसे हमेशा नष्ट कर देते हैं।
बड़े स्कैन के लिए वाकई आक्रामक कंप्रेशन कैसे?
Absolutool के भीतर बड़े स्कैन-आधारित PDF के लिए सबसे प्रभावी देशी कार्य-प्रवाह तीन टूल जोड़ने का है: मुफ़्त ऑनलाइन PDF से छवि निष्कर्षण से पन्नों को JPEG के रूप में बाहर लो, छवि कम्प्रेसर से downsample करो और चुनी हुई गुणवत्ता पर पुनः-एनकोड करो, फिर इमेज से पीडीएफ से दोबारा जोड़ो। इससे हर क़दम पर स्पष्ट गुणवत्ता-नियंत्रण के साथ पूर्वानुमेय आउटपुट मिलता है, सब कुछ ब्राउज़र में, किसी भी चरण में कोई अपलोड नहीं। किसी व्यावसायिक साइट पर एक ही «Compress Maximum» बटन दबाने से यह ज़्यादा मेहनत है, पर यह साइट के बड़े दर्शन से मेल खाता है: गंभीर टूल जो आपस में जुड़ते हैं, ऐसे उपयोगकर्ताओं की सेवा में जो पूर्वानुमेयता और गोपनीयता की क़द्र करते हैं।