MarkItDown bliver ofte sat i samme bås som webscrapere, og det er en forkert placering. Den har ingen crawler, ingen JavaScript-motor og ingen mulighed for at hente en URL og rydde sideskrald væk. Det, den gør, er at tage de bytes, du allerede har — en PDF, et Word-dokument, et regneark, en præsentation — og omsætte hele filen til Markdown, som en sprogmodel kan læse.
Jeg brugte et par uger på at køre Microsofts MarkItDown igennem en række rigtige dokumenter på en enkelt Mac, scorede hver tabel op mod et manifest, jeg havde skrevet før testen, og målte tiden på hver konvertering. Den korte version: På rene input er den hurtig og tro mod originalen, pakkeløsningen skjuler en 73 MB stor machine learning-runtime, du ikke bad om, og dens tabeller bryder sammen på måder, der godt nok består testen “overlevede teksten?”, men fejler testen “ligger data i den rigtige kolonne?”. Her er hele billedet med tallene.
Hvad MarkItDown egentlig er
MarkItDown er et Python-værktøj fra Microsoft, der konverterer filer og Office-dokumenter til Markdown, optimeret til LLM’er. Ret det mod en PDF, en .docx, en .xlsx, en .pptx, et billede, en HTML-fil eller nogle få andre formater, og du får Markdown tilbage. Det kan bruges på tre måder: via CLI (markitdown file.pdf -o out.md eller via stdin), via Python API (MarkItDown().convert(...)) og via en valgfri MCP-server til agent-workflows.
Det vigtigste at forstå er, hvad det ikke gør, for det påstår README’en heller ikke, og jeg bekræftede det i testen: ingen crawling, ingen JS-rendering, ingen link-følgning, ingen pagination og ingen readability-lignende udtræk af hovedindhold. Det er en konverter til hele dokumentet. Du leverer bytesene; den standardiserer dem. Den forskel afgør, om værktøjet hører hjemme i din stack eller ej, så jeg kommer til at vende tilbage til den flere gange.
Selve repoet er tungt efter GitHubs glans-tal — 165.282 stars og 11.790 forks pr. midten af juli 2026, MIT-licenseret, med nyeste release (v0.1.6) den 2026-05-26. Men stjernetallet afspejler først og fremmest, at det er et Microsoft-repo, som rider med på den generelle entusiasme for LLM-værktøjer, ikke modenheden af selve konverteringsmotoren. Der er også 833 åbne issues, og et par af dem er værd at kende, før du installerer det (mere om det nedenfor).
HTML til Markdown: hurtig og komplet, sideskrald inkluderet
Da resten af min scraper-anmeldelsesserie bruger de samme fire web-fixtures, fodrede jeg MarkItDown med de samme lokale HTML-filer — ikke for at bedømme den som scraper, men for at se, hvor god dens HTML-til-Markdown-konvertering er. På pænt taggede sider er den faktisk rigtig god.
Alle fire sider blev konverteret på standardinstallationen uden ekstra pakker, og hver eneste body-content probe overlevede. Wikipedia-artiklen “Web scraping” (226 KB) kom ud med sit overskrifts-træ intakt — én h1, syv h2’er, tolv h3’er, præcis som artiklens rigtige struktur — og 418 links bevaret som rigtige [tekst](url). Hockey-statistik-tabellen med 26×9 celler på Scrape This Site forms-siden blev til en ren GFM-pipetabel med 27 rækker (header + separator + 26 datarækker), inklusive tomme celler. Hastigheden var heller ikke et problem: median 48 ms for den lille quotes-side op til 352 ms for Wikipedia-siden på 226 KB.
Men der er et forbehold, og det er et designvalg snarere end en fejl. MarkItDown fjerner ikke sideskrald. Den konverterer hele <body>, så site-chrome følger med — og restindholdet vokser i takt med, hvor meget chrome siden har.
| Side | Output-tegn | Overskrifter (h1/h2/h3) | Links | Chrome-linjer |
|---|---|---|---|---|
| Books to Scrape | 10,478 | 1 / 0 / 0 | 94 | 0.6% (1/159) |
| Quotes to Scrape | 2,973 | 1 / 1 / 0 | 55 | 1.2% (1/86) |
| ScrapeThisSite forms | 3,385 | 1 / 0 / 0 | 31 | 6.7% (5/75) |
| Wikipedia Web scraping | 60,159 | 1 / 7 / 12 | 418 | 12.4% (42/338) |
På Books-forsiden, som næsten er fri for chrome, er kun 0,6% af outputlinjerne chrome. På Wikipedia er det 12,4% — 42 ud af 338 ikke-tomme linjer er “jump to content”, “toggle the table of contents”, “22 languages”, “retrieved from”, cookie- og licensfodnoter. Wikipedias vedligeholdelsesbannere (“This article needs additional citations”) bliver endda gengivet trofast som to-kolonners pipetabeller, og det er her ni tabelrækker kommer fra på en side uden en egentlig datatabel.
Det er ikke MarkItDown, der gør noget forkert. Det er en hel-dokument-konverter, ikke en readability-extractor: trofast HTML-til-Markdown er en anden opgave end ren artikeludtræk. Trafilatura og Firecrawl-lignende værktøjer forsøger at returnere kun hovedindholdet; MarkItDown returnerer siden. Under motorhjelmen fjerner dens _html_converter.py <script> og <style>, og sender derefter hele body videre til markdownify-biblioteket — uden nogen form for hovedindholds-heuristik i kæden. Hvis du kun vil have artiklen, er det forkert lag.
Hjemmebanen: PDF, DOCX, XLSX, PPTX
Dokumenter er det, MarkItDown er bygget til. Jeg testede den på rigtige offentlige filer — en arXiv-artikel med tekstlag, Bitcoin-whitepaperet, en scannet PDF uden tekst, som jeg selv havde rendret til at være helt uden tekst, samt DOCX/XLSX/PPTX-filerne fra MarkItDowns egen test-suite (seedet med UUID’er, så jeg kunne opdage stille datatab).
| Dokument | Input | Output-tegn | Probes | Median tid | Noter |
|---|---|---|---|---|---|
| arXiv 1706.03762 (PDF med tekstlag) | 2,2 MB | 40,174 | 7/7 | 3,7 s (warm) | titel, "Transformer", "BLEU", "References" er alle til stede |
| Bitcoin whitepaper (9 sider PDF) | 184 KB | 22,485 | 6/6 | 1,4 s | "Satoshi Nakamoto", "proof-of-work", "Conclusion" er til stede |
| Scannet PDF (intet tekstlag) | 89 KB | 0 | 0/4 | 15 ms | tomt output, ingen fejl, ingen OCR |
| DOCX (test.docx) | 136 KB | 4,651 | — | 70 ms | overskrifter + GFM-tabel; indlejrede UUID’er overlever |
| DOCX med ligninger | 15 KB | 240 | — | 101 ms | Office Math bevares som LaTeX |
| XLSX (test.xlsx) | 12 KB | 808 | — | 57 ms | hvert ark → ## ArkNavn + GFM-tabel |
| PPTX (test.pptx) | 278 KB | 2,047 | — | 52 ms | markører for slide-numre, tabeller, diagram → tabel |
Tekstudtrækket på PDF’erne med tekstlag var fremragende — 7 ud af 7 forudregistrerede probes på arXiv-paperet “Attention Is All You Need”, 6 ud af 6 på Bitcoin-whitepaperet — og ingen af Office-filerne mistede en eneste UUID-sentinel, så der var intet stille datatab på vedligeholdernes egne regressionsfixtures. En fin, snæver sejr: DOCX-stien (via mammoth) bevarer Office Math-ligninger som LaTeX og omsætter equations.docx til rigtig $$...$$-matematik. Hvis du sender matematik-tunge Word-dokumenter til en LLM, er det en reel, om end snæver, fordel, som jeg ikke fandt beskrevet andre steder.
To resultater på denne hjemmebane fortjener særlig opmærksomhed, fordi de mest sandsynligt vil bide dig i haserne.
Den scannede PDF, der forsvinder
Giv MarkItDown en billedbaseret PDF uden tekstlag, og den returnerer en tom streng. Nul tegn, ingen undtagelse, ingen advarsel — konverteret på omkring 15 ms, fordi der ikke er noget at udtrække. MarkItDowns PDF-sti er kun til tekstudtræk (pdfminer og pdfplumber under motorhjelmen), og den leveres uden OCR i standardinstallationen og uden nogen pip-extra.
Det er vigtigt i batchkørsler. En udvikler, der fodrer en mappe med PDF’er, hvor nogle er scanninger, får stille og roligt tomme resultater for de filer uden signal om, at noget blev sprunget over. Jeg tjekkede, at fixturet ikke var ødelagt, ved at køre pdfminers extract_text direkte på den — nul afstrippede tegn, intet tekstlag, bekræftet — så det tomme output er MarkItDowns reelle adfærd på en rigtig scan. Det reproducerer en længe åben OCR-fallback-mangel (#1268), som har været kendt upstream et stykke tid. Den dokumenterede løsning er den valgfrie Azure Document Intelligence-backend eller et plugin; ingen af delene er med i standardinstallationen.
PDF’er kommer ud som flad tekst, ikke struktur
På begge PDF’er med tekstlag producerede MarkItDown nul Markdown-markører for overskrifter. En PDF har ingen semantiske heading-tags, og MarkItDown gætter ikke på dem ud fra skriftstørrelse, så hver linje ender på brødtekstniveau. Tekstudtrækket er højt; strukturen er flad.
Det er ikke kun mit resultat. Offentlige tredjepartsbenchmarks scorer MarkItDowns PDF-heading-hierarki omkring 0,0 og tabeltrofastheden omkring 0,27, langt under Doclings 0,88 med TableFormer (se MarkItDown vs Docling vs Marker-sammenligningen og READoc-benchmarket). Mine fixtures reproducerer deres, og det styrker evidensen — mine tal stemmer med en ekstern kilde. Den trade-off, de samme benchmarks rapporterer, er, at MarkItDown kører omkring 100× hurtigere end Docling, hvilket passer med mine sekunder-og-ikke-minutter-tider på dokumenter, som et layout-model-værktøj bruger flere minutter på. Konklusionen: MarkItDown giver dig ren og hurtig PDF-tekst; den giver dig ikke PDF’ens struktur. Hvis overskrifter og tabeller skal overleve, er et layout-model-værktøj som Docling eller Marker det rigtige lag.
Tabeller: Indhold overlever altid, struktur gør ikke altid
Tabeller er stedet, hvor “overlevede teksten?” og “kan dataene bruges?” skilles ad, så jeg byggede en matrix med 13 cases — én <table> pr. case, hver scoret mod et manifest skrevet før testen — for præcist at kortlægge, hvilke former der holder, og hvilke der bryder sammen.
Overskriften er: MarkItDown mistede aldrig tabelindhold. Alle 13 cases beholdt 100% af deres forudregistrerede tokens. Strukturel trofasthed fordelte sig derimod i tre grupper. Syv ud af tretten gav et velstruktureret GFM-gitter (plain, header-colspan, 24-kolonne-bred, headerless, empty-cells, block-in-cell og højre-til-venstre arabisk). Fire blev ujævne, fordi Markdown ikke har noget begreb om en celle, der spænder over flere rækker eller kolonner, så rowspan, colspan og dårligt formede kilder giver korte rækker. Og to var decideret ødelagte.
De to ødelagte er værd at nævne. En nested tabel (en <table> inde i en <td>) bliver foldet fladt ind i linjen, så dens egne pipes og separatorrække havner i den overordnede celle og skaber en 14-“kolonne” junk-række. Og et bogstaveligt | inde i en celle bliver ikke escaped — celleteksten a | b bliver til to kolonner, x || y bliver til tre — så en tabel med to kolonner ender med rækker med to, tre og fire kolonner, og enhver Markdown-parser længere nede læser forkerte grænser. Mærkeligt nok bliver asterisker og backticks i celler escapet; det er kun pipes, der ikke bliver det. Rodårsagen er, at MarkItDowns HTML-sti bruger markdownifys standardhåndtering af tabeller, og dens egen subclass overskriver links, billeder og overskrifter, men ikke tabelceller. Den samme pipe-escapingsfejlklasse er en åben issue for CSV-konverteren (#2019), men den rettelse rører ikke den HTML-sti, jeg testede.
Den mere subtile fejl — den jeg helst ville have, at en data engineer så — er rowspan. Case t03 bliver ikke bare ujævn; den misaligner data stille og roligt. En rowspan=2-label (“Fruit”) bliver kun skrevet én gang, og rækken under bliver en kort to-kolonners række (| Banana | 8 |), så “Banana” havner under Group-kolonnen i stedet for Item. Hvert token er der. En naiv forbruger, der “læser den anden kolonne”, får den forkerte værdi. Den slags bug består en kontrol for tekstoverlevelse og korrumperer stille et datasæt.
Begrænsningen ved spans er i sig selv en kendt, registreret designbegrænsning (#1211, #1248) — et fladt GFM-pipegitter kan ganske enkelt ikke repræsentere spans eller nesting, så konverteren bytter struktur for fuldstændighed i indholdet. Der er også gode ting i blandingen: tabeller uden header får en syntetisk tom header-række (så data ikke i stilhed bliver gjort til en header), tomme celler bevares, og <caption> overlever som en tekstlinje over tabellen.
Installation og opstart: den skat en “letvægts-utility” ikke advarer dig om
Intet overraskede mig mere her, og det er det sted, hvor framing som “letvægts Python-utility” stille og roligt lover for meget.
For det første: Kør ikke pip install 'markitdown[all]'. På Python 3.14 falder den lydløst tilbage til markitdown 0.0.2 — en to år gammel version — hvilket jeg reproducerede live i en ren venv. At pinne versionen afslører hvorfor: pip install 'markitdown[all]==0.1.6' fejler, fordi [all]-extra’en låser youtube-transcript-api~=1.0.0, og på den nuværende PyPI er hver build i det interval begrænset til Python <3.14, mens de eneste builds, der er kompatible med 3.14, ligger uden for pinningen. Så resolveren går helt tilbage til den sidste release, hvis afhængigheder den kan opfylde. Det matcher en åben upstream issue (#2179). Løsningen er enkel — pin versionen og installer extras enkeltvis: pip install 'markitdown==0.1.6', og derefter pip install 'markitdown[pdf,docx,pptx,xlsx,xls]==0.1.6'. Hver af dem resolver rent; det er kun den kombinerede [all]-pakke, der har den giftige pin. (Denne fælde afhænger af Python-versionen — på Python 3.13 eller tidligere rammer begrænsningen måske ikke, så [all] kan resolve anderledes.)
For det andet: fodaftrykket. Standardinstallationen er 161 MB (en tom venv på 13 MB plus 148 MB). Heraf udgør onnxruntime (73 MB) og numpy (34 MB) tilsammen 107 MB — 66% af hele standardaftrykket — og begge trækkes ind af én hård afhængighed: magika, Googles ML-detektor til filtyper. Så en tekstkonverter leverer en 73 MB ONNX-inferensruntime med i grundinstallationen, før du overhovedet tilføjer en dokument-extra. Tilføj dokument-extras, og venv’en når 310 MB. Det er langt lettere end en headless-browser-stack, men hvis du forventede et rent pip install-og-kør-værktøj, så ved du nu, at en ONNX-runtime følger med.
For det tredje — og det er den eneste observation i hele min pakke, der klarer alle novelty-checks, jeg kørte — koster selv et rent import markitdown omkring 3,35 sekunder på denne maskine. Prisen ligger næsten helt ved importtid: markitdown._markitdown importerer hele converter-registret eager (2,56 s kumulativt, 76% af totalen), hvilket trækker pandas (594 ms, via XLSX-konverteren), python-pptx (427 ms), magika (354 ms) og requests (270 ms) ind — uanset om du nogensinde konverterer de formater. For en langvarig service er den pris amortiseret og ligegyldig. For et CLI-kald eller en serverless cold start er det en reel per-process skat, som mærkatet “letvægts-utility” ikke får dig til at forvente. (Fair note: Det er én profileret kørsel, behandlet som én observation, ikke en flerdobbeltdistribution.)
Skala: den crasher ikke, men sæt CPU af til PDF’er og RAM af til regneark
Jeg pressede fire store emner igennem, hver i sin egen proces, så peak memory ikke blev forurenet af en tidligere kørsel. Intet crashede. Omkostningsprofilen er dog meget skæv.
| Emne | Input | Output-tegn | Median tid | Peak RSS Δ |
|---|---|---|---|---|
| NIST SP 800-53r5 (492-siders PDF) | 5,9 MB | 1,625,365 | 192,5 s | +40 MB |
| XLSX 50.000 rækker × 8 kolonner | 2,1 MB | 3,722,955 | 62,1 s | +374 MB |
| arXiv 1706.03762 (~15-siders PDF) | 2,2 MB | 40,174 | 12,6 s | +25 MB |
| XLSX 200 rækker × 64 kolonner | 46 KB | 120,129 | 2,9 s | +22 MB |
Den 492 sider lange NIST PDF tog median 192,5 sekunder — omkring 3,2 minutter, eller 0,39 s/side — fordi pdfplumber kører formdetektion baseret på tekstposition på hver side. Peak RSS lå stadig kun på +40 MB, så den er CPU-bundet, ikke memory-bundet. Selv den 15-siders arXiv PDF tog 12,6 sekunder i sin egen isolerede proces, cirka 3,4× de 3,7 sekunder, som den samme fil viste varm inde i min dokument-suite. Den forskel er cold-process-omkostningen, og den bekræfter, at det er sidearbejdet, ikke den rå filstørrelse, der driver tiden. Hvis du vil have ét tal, du kan overføre, så brug de isolerede 12,6 s.
Regnearkssiden vender flaskehalsen om. En 2,1 MB stor XLSX med 50.000 rækker voksede til +374 MB peak RSS (og 3,7 millioner outputtegn), fordi konverteren indlæser hele arket og bygger én stor Markdown-streng. Den praktiske tommelfingerregel er derfor lige ud ad landevejen: store PDF’er kræver minutter af CPU; store regneark kræver hundreder af MB RAM. Det er tal fra én maskine på macOS arm64 og Python 3.14, og per-side- og per-række-konstanterne er platformsafhængige — men formen på resultaterne (PDF er langsom og CPU-bundet, XLSX er memory-tung, intet crasher) er den del, der går igen.
Hvor Thunderbit passer ind — og hvor det ikke gør
Prøv Thunderbit til webdata-udtræk
Det her er den ene sammenligning, hvor det ville være let at overdrive, så jeg sætter grænsen forsigtigt. MarkItDown og Thunderbit løser beslægtede problemer, ikke det samme problem.
MarkItDown konverterer filer, du allerede har. Thunderbit henter først siden. Thunderbits /distill-endpoint omsætter en levende webside til ren Markdown, klar til LLM’er — og håndterer JavaScript-rendering, anti-bot og dynamisk indhold, som MarkItDown slet ikke har værktøjerne til — og /extract-endpointet returnerer struktureret JSON, der matcher et schema, ikke bare rå Markdown. For udviklere er det tilgængeligt som API (POST /distill / POST /extract), MCP-server og CLI (npx @thunderbit/thunderbit-cli) oven på én AI-motor, den samme som ligger bag extensionen med 100.000+ brugere.
Så de overlapper kun på ét punkt — begge kan levere “LLM-ready Markdown” — men input-domænet er forskelligt: Thunderbits distill tager en URL på det åbne web, MarkItDown tager en lokal fil. De er ikke udskiftelige, og det vil jeg ikke lade som om. Den realistiske stack bruger begge: hent og crawl webben med Thunderbit (eller en Firecrawl-lignende tjeneste), og normalisér derefter de blandede lokale dokumenter, du også har — PDF’er, slides og regneark — med MarkItDown. Den ene håndterer netværket; den anden håndterer arkivskuffen.
Fordele og ulemper
Styrker
- Fuld tekstgengivelse på ren HTML (4/4 sider), med overskriftstræer og links trofast bevaret
- Høj tekstgengivelse på PDF/DOCX (arXiv 7/7 probes, Bitcoin 6/6) og intet stille datatab på vedligeholdernes egne Office-fixtures
- Office Math-ligninger bevares som LaTeX — en reel nichefordel
- Crashede aldrig på nogen af skala-testene, helt op til en 492-siders PDF og en XLSX med 50k rækker
- Nemt at kalde: CLI,
convert(), piping via stdin og en valgfri MCP-server - MIT-licenseret, aktivt vedligeholdt af Microsoft og med responsivt issue-tracker
Svagheder
- Beholder sideskrald — op til 12,4% chrome-linjer på Wikipedia; er ikke en artikel-extractor
- Tabeller bryder på spans, nesting og pipes inde i celler (2/13 ødelagte, 4/13 ujævne), og rowspan kan stille flytte data til forkert kolonne
- Scannede/billedbaserede PDF’er returnerer tomt output uden OCR og uden fejl
- PDF-output har ingen overskriftsstruktur (matcher offentlige benchmarks)
- 161 MB standardinstallation med en 73 MB ONNX-runtime; ca. 3,35 s kold import
[all]-extra’en falder stille tilbage til en to år gammel 0.0.2 på Python 3.14
Hvem bør bruge det — og hvem bør lade være
Vælg MarkItDown, hvis du standardiserer en bunke blandede lokale dokumenter — Word, Excel, PowerPoint, PDF’er med tekstlag — til Markdown i en LLM-pipeline, og du går mere op i komplet tekst end i bevaret struktur. Som sidste led i en batchjob-kæde, der fodrer en model med ren tekst, er den hurtig, trofast og gratis.
Spring det over, eller brug det sammen med noget andet, hvis din opgave er en af disse: du vil kun have hovedartiklen fra en webside (brug et readability- eller Firecrawl-lignende værktøj); du vil have en PDF’s overskrifter og tabeller til at overleve intakt (så er du i Docling- eller Marker-territorium); eller dine input inkluderer scannede dokumenter, som kræver OCR (du skal bruge Azure-backenden eller et helt andet værktøj). Og hvis du troede, du var på jagt efter en scraper — altså noget, der henter og crawler — så er det her slet ikke det.
Den foreløbige score, jeg gav den på et scraper-formet rubric, ender på 60/100, og den lave total skyldes, at jeg bedømmer en konverter ud fra en crawlers test. På dens egen hjemmebane er teksttrofastheden høj; de svage punkter er strukturelle (tabeller, PDF-overskrifter) og relateret til pakningen (fodaftryk, import, [all]-fældene), ikke til tekstkvaliteten. Bedøm den for det, den er — en fil-til-Markdown-konverter — og den er et solidt, velholdt værktøj med nogle skarpe kanter, du bør kende, før du sætter det i produktion.
Ofte stillede spørgsmål
Er MarkItDown en webscraper?
Nej. Den har ingen crawler, ingen JavaScript-rendering, ingen link-følgning og ingen pagination. Den konverterer de filer og dokumenter, du allerede har — PDF, DOCX, XLSX, PPTX, billeder, HTML — til Markdown. Hvis du skal hente og crawle levende websider, skal du bruge et scraping-værktøj som Thunderbit eller Firecrawl; MarkItDown er trinnet bagefter, hvor de hentede eller lokale filer bliver til ren Markdown.
Hvorfor installerer pip install markitdown[all] en gammel version?
På Python 3.14 låser [all]-extra’en youtube-transcript-api~=1.0.0, og alle builds i det interval er begrænset til Python-versioner under 3.14. Resolveren kan ikke opfylde pinningen, så den falder stille tilbage til markitdown 0.0.2, en to år gammel release. Løsningen er at pinne versionen og installere extras enkeltvis: pip install 'markitdown==0.1.6', og derefter tilføje 'markitdown[pdf,docx,pptx,xlsx,xls]==0.1.6'. Det er registreret som issue #2179.
Kører MarkItDown OCR på scannede PDF’er?
Ikke i standardinstallationen. Dens PDF-sti er kun til tekstudtræk, så en billedbaseret PDF uden tekstlag returnerer en tom streng — ingen fejl, ingen advarsel. OCR kræver den valgfrie Azure Document Intelligence-backend eller et plugin, og ingen af delene følger med som standard. Det er et længe kendt hul (issue #1268).
Hvor godt håndterer MarkItDown tabeller?
Indholdsmæssigt rigtig godt — i min test med 13 cases bevarede den 100% af tabelindholdet i alle tilfælde. Strukturelt afhænger det af formen: simple, brede, headerløse tabeller og tabeller med tomme celler kommer ud som pæne GFM-gitre, men rowspan og colspan bliver ujævne (og rowspan kan stille flytte data til forkert kolonne), nested tabeller bliver fladet ud til junk-rækker, og bogstavelige pipe-tegn inde i celler bliver ikke escaped. Markdown-formatets flade tabelmodel kan simpelthen ikke repræsentere spans eller nesting.
Er MarkItDown hurtig nok til store dokumenter?
Den crasher ikke på store filer, men du skal budgettere ressourcer efter type. En PDF på 492 sider tog omkring 3,2 minutter (cirka 0,39 s/side), fordi den laver formdetektion pr. side, og den er CPU-bundet. Et regneark med 50.000 rækker blev færdigt på omkring et minut, men brugte +374 MB RAM, fordi den bygger én stor Markdown-streng i hukommelsen. Til store PDF’er skal du regne med minutter af CPU; til store regneark skal du regne med hundreder af MB RAM.
Prøv Thunderbit til webdata-udtræk Get Started Free
