मुफ़्त PDF से HTML कनवर्टर

PDF → HTML रूपांतरण के बारे में

यह टूल PDF फ़ाइलों से टेक्स्ट निकालने के लिए PDF.js का उपयोग करता है और इसे सिमेंटिक HTML में रेंडर करता है। दस्तावेज़ों को वेब प्रारूपों में रूपांतरित करने के लिए आदर्श।

सामान्य उपयोग के मामले

• दस्तावेज़ संग्रहण · दीर्घकालिक डिजिटल संरक्षण और वेब एक्सेस के लिए PDF को HTML में रूपांतरित करें।
• सामग्री माइग्रेशन · CMS या वेब प्रकाशन के लिए PDF से संरचित HTML में टेक्स्ट निकालें।
• टेक्स्ट निष्कर्षण · विश्लेषण या पुन: उपयोग के लिए PDF से साफ़ टेक्स्ट प्राप्त करें।
• वेब प्रकाशन · तेज़ लोडिंग और बेहतर सुगम्यता के लिए अपने दस्तावेज़ों को वेब-अनुकूल प्रारूप में रूपांतरित करें।
• डेटा प्रसंस्करण · आगे रूपांतरण या एकीकरण के लिए PDF सामग्री तैयार करें।

अक्सर पूछे जाने वाले प्रश्न

कौन से PDF आकार समर्थित हैं?

यह टूल आपके ब्राउज़र के आधार पर लगभग 10 MB तक के PDF प्रसंस्कृत कर सकता है। बहुत बड़े या जटिल PDF अधिक समय ले सकते हैं।

क्या यह PDF फ़ॉर्मेटिंग संरक्षित करता है?

टूल टेक्स्ट सामग्री निकालता है और इसे अनुच्छेदों में रेंडर करता है। जटिल लेआउट, छवियाँ और शैलियाँ HTML में सरल होती हैं।

क्या मैं HTML डाउनलोड कर सकता हूँ?

हाँ। रूपांतरित सामग्री को .html फ़ाइल के रूप में सहेजने के लिए "HTML डाउनलोड करें" पर क्लिक करें, जो किसी भी ब्राउज़र या संपादक में खुलती है।

PDF का संक्षिप्त इतिहास: PostScript से एक portable page तक

Portable Document Format John Warnock की सोच थी, जो Adobe Systems के सह-संस्थापक थे और जिन्होंने पहले PostScript का सह-आविष्कार किया था, वह page-description language जिसने 1985 में Apple LaserWriter के साथ शुरुआत करते हुए desktop publishing को संभव बनाया। PostScript असाधारण रूप से शक्तिशाली था लेकिन यह एक programming language था, न कि कोई document format: एक PostScript file वर्णन करती थी कि interpreter में feed होने पर page को कैसे render किया जाए, लेकिन यह वास्तव में उन machines पर consistently पढ़ने, संपादित करने या render करने के लिए नहीं थी जिनके पास सही fonts नहीं थे।

1991 में, Warnock ने एक internal Adobe memo प्रसारित किया जो Camelot Project के नाम से जाना जाने लगा। आधार यह था: Adobe को एक single file format बनाना चाहिए जो किसी भी document (उसके fonts, layout, vector graphics और images सहित) को capture कर सके और उसे किसी भी computer पर, किसी भी operating system पर, चाहे कोई भी application ने originally बनाया हो, identically reproduce कर सके। जब तक proposal को परिष्कृत किया गया, तब तक project को एक product name मिल गया था: Adobe Acrobat।

Acrobat 1.0 और PDF 1.0 को नवंबर 1992 में Las Vegas में Comdex Fall trade show में demonstrate किया गया और जून 1993 में customers को ship किया गया। Adobe का महत्वपूर्ण commercial निर्णय 1994 में आया जब उसने Acrobat Reader को मुफ़्त देना शुरू किया, जो HTML browsers के साथ जो हुआ था उसे mirror करता था और millions of installations की एक base तैयार की। इस format में कई revisions हुए: PDF 1.1 (1996, external links और security), 1.2 (1996, AcroForms), 1.3 (2000, digital signatures), 1.4 (2001, transparency), 1.5 (2003, object streams और JPEG 2000), 1.6 (2004, OpenType और 3D), 1.7 (2006)। 2008 में, PDF 1.7 को ISO 32000-1:2008 के रूप में प्रकाशित किया गया; PDF 2.0 ISO 32000-2:2017 के रूप में आया, जिसका एक substantially revised second edition (ISO 32000-2:2020) था जिसमें errata शामिल थे और जो वर्तमान authoritative reference है।

मुख्य standard के साथ कई विशेष PDF profiles मौजूद हैं: PDF/A (ISO 19005-1:2005, 2011 में -2 और 2012 में -3 के साथ) archival profile है जो external resources या future software पर निर्भर features को prohibit करती है (कोई JavaScript नहीं, कोई audio नहीं, कोई encryption नहीं, fonts embedded होने चाहिए); PDF/X printing industry द्वारा उपयोग किया जाने वाला prepress profile है; PDF/E technical drawings के लिए engineering profile है; PDF/UA (ISO 14289-1:2014) universal-accessibility profile है जिसके लिए logical structure और tagging आवश्यक है ताकि screen readers content को reading order में present कर सकें; PDF/VT personalised mail merge में उपयोग किया जाने वाला variable-and-transactional profile है।

PDF-to-HTML structurally कठिन क्यों है

PDF, अपने सबसे निचले स्तर पर, numbered objects (dictionaries, arrays, strings, numbers, names और binary streams) का एक collection है जिसके अंत में एक cross-reference table होती है जो reader को पूरी file parse किए बिना किसी भी object पर jump करने देती है। ये objects एक tree बनाते हैं जो एक Catalog object में rooted होती है जो Pages tree की ओर इंगित करती है, जिसमें Page objects होते हैं। हर Page एक content stream को reference करता है: वे actual instructions जो page को draw करते हैं।

एक content stream एक छोटी language में compact graphical operators की एक sequence है जो PostScript से संबंधित है लेकिन Turing-complete नहीं है। text के लिए, यह Tf (font और size set करें), Td (text position move करें), Tm (text matrix set करें), Tj (एक string दिखाएँ), TJ (kerning के लिए optional individual character offsets के साथ strings का एक array दिखाएँ), और ET (text end करें) का उपयोग करती है। महत्वपूर्ण बात यह है कि सब कुछ positional है। body text का एक paragraph, paragraph के रूप में stored नहीं होता। यह Tj या TJ commands की एक series के रूप में stored होता है, जिनमें से हर एक page पर एक specific x और y coordinate पर एक glyph या glyphs की एक छोटी run draw करता है। किसी sentence, paragraph, heading, list, या column की कोई अवधारणा नहीं है, केवल यह सवाल कि हर character physically कहाँ बैठता है।

HTML इसके विपरीत है: semantic elements का एक flowing tree जहाँ layout renderer की ज़िम्मेदारी है और वही HTML phone, desktop, या screen reader के अनुसार reflow कर सकता है। इसलिए PDF को HTML में convert करने के लिए एक ऐसी structure को reverse-engineer करना आवश्यक है जिसे PDF को कभी record करने की आवश्यकता नहीं थी। एक converter को हर page पर text के spatial distribution को देखकर अनुमान लगाना होता है:

• कौन से characters एक ही word से संबंधित हैं (font के average advance width के विरुद्ध glyphs के बीच gap को मापकर);
• कौन से words एक ही line से संबंधित हैं (tolerance के भीतर y-coordinate पर clustering करके);
• कौन सी lines एक ही paragraph से संबंधित हैं (baseline differences और indentation patterns detect करके);
• कौन से paragraphs एक ही column से संबंधित हैं (whitespace के vertical gutters ढूँढकर);
• और multiple columns, footnotes और side notes में reading order।

इनमें से कोई भी content stream को क्रम में पढ़कर हल नहीं होता, क्योंकि stream में क्रम ज़रूरी नहीं कि reading order हो। PDF बनाने वाले layout engine ने elements को rendering के लिए सबसे efficient क्रम में draw किया होगा, जो zig-zag में top-to-bottom, या font के अनुसार, या रंग के अनुसार हो सकता है। एक single paragraph का text underlying stream में neighboring paragraphs के text के साथ interleaved हो सकता है। इसीलिए PDF extractors जो केवल stream order में strings concatenate करते हैं, वे single-column novel से अधिक complex किसी भी चीज़ के लिए mangled output तैयार करते हैं।

यदि PDF tagged है: अर्थात, यदि उसके लेखक ने visual content के साथ एक structure tree शामिल किया है, तो काम बहुत आसान हो जाता है। एक tagged PDF में structure elements का एक hierarchy होता है (paragraph के लिए P, headings के लिए H1 से H6, list के लिए L, list item के लिए LI, Table, TR, TD, Figure, Caption) जो HTML के semantic vocabulary को mirror करता है। PDF/UA accessibility के लिए tagging को अनिवार्य करता है क्योंकि untagged PDFs assistive technology के लिए essentially opaque हैं। व्यवहार में, हालाँकि, अधिकांश PDFs in the wild tagged नहीं हैं, या authoring tool द्वारा ठीक से tagged नहीं हैं, इसलिए एक robust converter को tags मौजूद होने पर भी layout analysis पर fall back करना होता है।

प्रमुख open-source PDF rendering libraries

PDF.js Mozilla द्वारा लिखी गई JavaScript library है, जिसे originally जून 2011 में Andreas Gal की अगुवाई में एक experimental project के रूप में launch किया गया था। यह बिना किसी native plugin के HTML5 canvas और JavaScript का उपयोग करके browser में PDFs को पूरी तरह parse और render करती है। PDF.js को मार्च 2013 में Firefox 19 से शुरू होकर Firefox में default PDF viewer के रूप में bundle किया गया, जिसने Adobe Reader plugin की जगह ली। यह एक JavaScript API expose करती है जो एक page को positional metadata के साथ text content extract करने देती है (हर text run अपने x, y, width, height, font name और font size के साथ वापस आता है)। यह tool PDF.js पर बना है।

Poppler xpdf से forked एक C++ library है, जो venerable PDF viewer है जिसे Glyph and Cog 1990 के दशक के अंत से maintain करता आया है। Poppler, Linux desktop environments के PDF-rendering features (GNOME में Evince, KDE में Okular), pdftotext और pdftohtml command-line utilities, और कई server-side PDF processing pipelines को power करता है। MuPDF, Artifex Software द्वारा (वही कंपनी जो Ghostscript maintain करती है), एक छोटी और तेज़ C library है जो embedded use के लिए लक्षित है। PDFium वह engine है जो built-in PDF viewing के लिए Google Chrome और Microsoft Edge के अंदर ship होता है; यह proprietary Foxit PDF SDK का एक fork है जिसे Google और Foxit ने मई 2015 में jointly open-source किया। qpdf एक C++ library और command-line tool है जो rendering के बजाय structural manipulation पर focused है, यह visual content बदले बिना PDFs को decompress, encrypt, decrypt, linearise और rewrite कर सकता है।

HTML output तैयार करने के लिए विशेष रूप से, सबसे महत्वपूर्ण purpose-built project pdf2htmlEX है, जो originally Lu Wang ने 2012 में लिखा था और अब एक community group द्वारा maintain किया जाता है। pdf2htmlEX अधिकांश converters से एक अलग approach लेता है: semantic HTML reconstruct करने की कोशिश करने के बजाय, यह हर text run के लिए absolutely positioned div elements emit करके, original fonts को Web Open Font Format (WOFF) files के रूप में embed करके, और जहाँ आवश्यक हो CSS transforms का उपयोग करके PDF के visual layout को यथासंभव faithfully reproduce करता है। परिणाम एक ऐसा webpage है जो original PDF से अलग नहीं दिखता, लेकिन underlying HTML, position: absolute spans की एक दीवार है जिसका कोई semantic meaning नहीं है।

Layout fidelity बनाम semantic flow, केंद्रीय trade-off

यह PDF-to-HTML conversion में केंद्रीय trade-off है: आप layout fidelity रख सकते हैं या semantic flow, लेकिन दोनों एक साथ रखना कठिन है। pdf2htmlEX जैसा fidelity-first converter ऐसा output तैयार करता है जो original जैसा print होता है और दिखता है लेकिन screen reader के लिए opaque है और phone screen पर rigid है। pdftotext या PDF.js के getTextContent जैसा flow-first converter जिसके बाद simple paragraph reconstruction होती है, clean, readable, accessible HTML तैयार करता है, लेकिन source की visual richness, रंगों, exact fonts, image placement, table grids और original page की किसी भी झलक को खो देता है।

Absolutool tool firmly flow-first side पर है। यह PDF.js का उपयोग करके text content extract करता है और इसे paragraphs के रूप में emit करता है, pixel-perfect reproduction पर readability, accessibility और छोटे file size को प्राथमिकता देता है। यदि आपको visual reproduction route चाहिए (हर glyph अपनी original position पर, original fonts embedded, exact pagination preserved) तो pdf2htmlEX देखें; यदि आपको readable-paragraphs route चाहिए (content reuse, web publishing, search-indexable HTML, screen-reader-accessible output) तो यह tool उद्देश्य के लिए उपयुक्त है।

Embedded fonts, images, और उनके नीचे vector content

एक PDF कोई भी font embed कर सकता है, और original look preserve करना चाहने वाले converter के पास तीन options हैं। Embed-and-serve: converter PDF से हर embedded font extract करता है, उसे browsers के समझ में आने वाले format में web font के रूप में repackage करता है (WOFF या, 2018 से, WOFF2 जिसमें अधिक aggressive Brotli compression है), और generated HTML से उसे link करता है। यह original look preserve करता है लेकिन file size बढ़ाता है और licence issues हो सकते हैं यदि font के embedding rights web redistribution तक extend नहीं होते। Substitute: हर embedded font को एक similar system font से map करें (एक serif PDF font Times New Roman या Georgia बन सकती है), एक छोटे, cleaner output के बदले में कुछ visual drift स्वीकार करते हुए। Ignore: font information को पूरी तरह discard करें और browser को default body font apply करने दें, जो अधिकांश flow-first converters करते हैं क्योंकि user browser की normal styling में HTML पढ़ता है।

Images एक similar choice प्रस्तुत करती हैं। एक converter embedded images को separate files के रूप में extract करके HTML से reference कर सकता है; पूरे pages को images के रूप में rasterise करके inline embed कर सकता है (PDF को एक glorified gallery में बदलते हुए); या images को पूरी तरह drop करके केवल text emit कर सकता है, जो visual reproduction के बजाय content reuse के लिए उपयुक्त है और यही इस tool का choice है। Vector content (PDF के graphics operators द्वारा drawn lines, shapes, paths) और भी awkward है, क्योंकि semantic HTML में इसे represent करने का कोई clean तरीका नहीं है; इसे preserve करना चाहने वाले converters inline SVG या PNG rasterisation पर fall back करते हैं।

जब PDF एक picture हो: scanned documents के लिए OCR fallback

दुनिया में PDFs का एक significant हिस्सा वास्तव में structured sense में documents नहीं हैं, ये paper documents के scanned images हैं, PDF wrappers में packaged हैं क्योंकि PDF internet पर paper-like चीज़ें भेजने का universal format है। एक scanned PDF में कोई text content stream नहीं होती; हर page एक single embedded raster image है जो text दर्शाती है लेकिन इसे machine-readable characters के रूप में contain नहीं करती। ऐसे PDF से text extract करने के लिए Optical Character Recognition (OCR) की आवश्यकता है, जो text extraction से fundamentally अलग operation है।

प्रमुख open-source OCR engine Tesseract है, जिसे originally 1985 और 1995 के बीच HP Labs में विकसित किया गया था, 2005 में open-source किया गया, और Google ने 2006 से लगभग 2018 तक इसे maintain किया जब तक Google ने primary stewardship एक community group को नहीं सौंपी। Tesseract सौ से अधिक languages support करता है, हर major platform पर चलता है, और countless desktop और server tools के OCR features को power करता है। Apple का Vision framework, 2017 से macOS और iOS पर उपलब्ध, एक fast और accurate text-recognition API शामिल करता है जिसका उपयोग OS के built-in screenshot और photo apps करते हैं। Google Cloud Vision, Azure Computer Vision, और Amazon Textract प्रमुख cloud OCR services हैं; documents के लिए विशेष रूप से, Textract और Azure का Document Intelligence दोनों raw OCR से परे जाकर tables, key-value pairs और form fields पहचानते हैं।

पूरी तरह client-side चलने वाला browser-based PDF-to-HTML converter सामान्यतः OCR नहीं कर सकता, OCR models कम से कम tens of megabytes के होते हैं और inference user के laptop पर interactively चलाने के लिए बहुत धीमा है। यदि आपके PDF में extractable text के बिना scanned pages हैं, तो यह tool उन pages के लिए empty output तैयार करेगा, और सही अगला कदम एक अलग OCR tool या server-side service है।

लोग PDFs को HTML में क्यों convert करते हैं

Use cases कुछ recurring patterns में आते हैं:

• Legacy reports के archives वाले publishers: annual reports, white papers, research papers, government publications, technical manuals को HTML में convert करते हैं ताकि content को हर visitor को file download करने के लिए मजबूर किए बिना directly browser में पढ़ा जा सके। HTML versions navigate करने में आसान हैं (आप किसी specific section से link कर सकते हैं), phone पर तेज़ी से load होते हैं, और search engines द्वारा crawlable हैं।
• Bloggers और content marketers अपने authored या licensed PDFs को HTML में convert करते हैं ताकि वे content को articles के रूप में republish कर सकें, text को फिर से type किए बिना उसका पुनः उपयोग करते हुए।
• Web archivists preservation projects के हिस्से के रूप में PDFs को HTML में convert करते हैं, इस सिद्धांत पर कि HTML दशकों तक एक complex binary format की तुलना में अधिक durable है जिसकी specification कई हज़ार pages लंबी है।
• Mobile reading apps और read-it-later services PDFs को HTML में convert करते हैं ताकि articles उनके reader views में खुलें, user के preferred font और font size, dark mode और adjustable line length के साथ।
• Screen-reader users PDFs को HTML में convert करते हैं क्योंकि untagged PDFs assistive technology के लिए essentially opaque हैं, लेकिन उचित paragraphs और headings के साथ HTML rendering को साफ़-साफ़ पढ़ा जा सकता है।
• Knowledge-management workflows PDFs को HTML में convert करते हैं ताकि content को search indexes, full-text databases और large-language-model context windows में feed किया जा सके, जिनमें से कोई भी PDF format को natively नहीं समझता, लेकिन सभी plain text और HTML को अच्छी तरह handle करते हैं।
• Researchers और academics journal articles के PDFs से text extract करते हैं ताकि citation managers, reference databases, या text-mining pipelines में feed किया जा सके जो हज़ारों papers में patterns ढूँढते हैं।

इनमें से हर एक की requirements थोड़ी अलग हैं, लेकिन एक common thread है: user PDF की content (शब्द, structure, अर्थ) चाहता है बिना उस rigid page-bound format से bound हुए जो original document ने चुना।

अधिक प्रश्न

मेरा converted HTML original PDF से अलग क्यों दिखता है?

यह tool flow-first है: यह text extract करता है और आपके browser के default font में clean paragraphs emit करता है, visual fidelity पर readability, accessibility और search-indexability को प्राथमिकता देता है। यदि आपको original layout का pixel-perfect reproduction चाहिए (embedded fonts, exact positioning, original colours) तो pdf2htmlEX जैसे fidelity-first tools देखें, जो absolutely-positioned div elements emit करते हैं जो source PDF से visually match करते हैं लेकिन ऐसा HTML तैयार करते हैं जो screen readers के लिए essentially unreadable है और phone screens पर rigid है।

मेरा multi-column PDF scrambled क्यों आ रहा है?

PDF reading order store नहीं करता, केवल positions। एक converter को text के spatial distribution से column boundaries का अनुमान लगाना होता है। simple two-column layouts के लिए heuristic आमतौर पर काम करती है; complex layouts के लिए जिनमें side notes हों, body text के साथ interleave होने वाले footnotes हों, या text जो column gutter पार करे, यह out-of-order output तैयार कर सकती है। यदि आपके पास tagged PDF है (जिसमें structure tree शामिल है), तो accuracy नाटकीय रूप से बेहतर है; untagged PDFs के लिए, परिणाम इस बात पर निर्भर करता है कि columns whitespace द्वारा कितनी clearly physically separated हैं।

मेरा PDF scanned है (केवल images), कुछ extract क्यों नहीं हो रहा?

एक scanned PDF में कोई text content नहीं होता, हर page text का एक raster image है न कि वह text जिसे parser पढ़ सके। text extract करने के लिए OCR (Tesseract, Google Cloud Vision, Apple का Vision framework, आदि) की आवश्यकता है, जो PDF parsing से fundamentally अलग operation है। यह tool OCR engine bundle नहीं करता क्योंकि models browser tool के साथ ship करने के लिए बहुत बड़े हैं। सही अगला कदम एक dedicated OCR service या built-in OCR वाला desktop tool है।

क्या मैं password-protected PDF convert कर सकता हूँ?

यदि PDF में open password है (इसे view करने के लिए password type करना होगा), तो PDF.js convert करने के बजाय error throw करेगा। यदि PDF में केवल permissions password है (खोलना free है लेकिन printing/copying restricted है), तो behaviour अलग-अलग होता है, अधिकांश modern PDF.js builds permissions का सम्मान करते हैं और text extract करने से मना कर सकते हैं। किसी भी स्थिति में, सबसे clean रास्ता है original PDF tool में पहले protection हटाएँ, फिर convert करें। जो PDF आप legally own करते हैं उसकी protection हटाना ठीक है; जो PDF आप own नहीं करते उसकी protection हटाना ठीक नहीं हो सकता।

संबंधित टूल