Drop a PDF into the zone below and every page comes back as an uncompressed Windows bitmap. No compression, no codec, no ambiguity: every byte in the file maps directly to one color channel of one pixel, and that is the entire reason anybody still specifies BMP. The price is size. A single A4 page at 300 dpi is about 26 MB, and nothing downstream will shrink it. Choose the resolution, convert a page range, and the archive is compressed for the download even though the bitmaps inside it are not. Nothing is uploaded and the work runs on your own processor.
Your files are read by JavaScript running on your own machine. There is no upload, no queue, and no copy on our server to delete later.
Drag a card to reorder it, or use the arrows under each card. The order here is the order in the output. Each card is a preview of the finished page, so what you see is what the PDF will contain.
Esc close ← → move R rotate
Starting
This is your processor doing the work, so the time it takes depends on your machine and not on how many other people are on the site.
The converter above is ready. The guide below is mostly a warning about size, and a specification - the exact arithmetic behind a 26 megabyte page, what gets written into the header and why two of those fields decide whether the file lands correctly downstream, how the download stays manageable anyway, and who genuinely needs this rather than PNG.
Two minutes, nothing to install, no account for your first run. This PDF to BMP converter renders the pages and writes the bitmap bytes inside the tab you are reading, so every step happens on your own hardware.
Click the drop zone above or drag the file anywhere onto this page. The document is parsed as it lands and the card shows page one with the page count, so you can confirm the right file before spending an operation.
This matters more here than for any other format, because nothing downstream will compress the result. An A4 page at 150 dpi is about 6.5 MB. The same page at 600 dpi is about 104 MB. Pick the resolution the receiving system actually asks for rather than the highest one on the list.
Leave the Pages field empty only for short documents. For anything longer, type a range the way you would in a print dialog: 1-5, or 2,7,11-14. Twenty pages at 300 dpi produces half a gigabyte of bitmaps, which is a real constraint rather than a theoretical one.
Press Convert to BMP. Several pages arrive as a ZIP, and unlike every other format here that archive is genuinely compressed, because uncompressed bitmaps squash by roughly an order of magnitude. Extract it and you have the full size bitmaps the target system needs.
BMP applies no compression at all. That makes the final file size something you can calculate exactly before you convert anything, rather than a number you discover afterwards.
A 24 bit bitmap stores three bytes per pixel, one each for blue, green and red, in that order. Rows are padded up to a four byte boundary. Add a 14 byte file header and a 40 byte info header and the whole file comes to: width x 3, rounded up to a multiple of 4, multiplied by height, plus 54 bytes. There is nothing else in it.
| Resolution | A4 page in pixels | BMP file size |
|---|---|---|
| 72 dpi | 595 x 842 | about 1.5 MB |
| 96 dpi | 794 x 1,123 | about 2.7 MB |
| 150 dpi | 1,240 x 1,754 | about 6.5 MB |
| 300 dpi | 2,480 x 3,508 | about 26 MB |
| 600 dpi | 4,960 x 7,016 | about 104 MB |
Resolution applies to the width and the height together, so each step down that table roughly quadruples the file rather than doubling it. A twenty page report at 300 dpi is half a gigabyte of bitmaps. Nothing has gone wrong when you see that number. It is what the format is, and it is the one thing to plan around before you start.
The tool budgets 900 million output pixels across a run and refuses anything past that, telling you to lower the resolution instead of freezing your browser. The check happens before a single page is rendered, so a refusal costs you nothing at all.
Ask the receiving system what it needs before you pick a resolution. Industrial and legacy software usually states an exact expected pixel size, and rendering above it means the system downsamples your file on the way in. You will have paid for every one of those bytes and gained nothing for them.
There is an obvious tension here. You need uncompressed files at the far end, and downloading half a gigabyte to get them is unreasonable. The ZIP resolves it, and this is the one tool in the suite where that archive is genuinely doing work.
Every other format in this suite is already entropy coded. PNG has run Deflate across its own pixel data, and JPEG, WebP and AVIF are lossy codecs whose output is close to incompressible by construction. Deflating those inside an archive spends seconds of your processor to save a fraction of a percent, and on some inputs hands back an archive larger than the files that went into it. So they are stored rather than deflated.
A bitmap is the opposite case. It is raw pixel data with no compression applied, and a rendered document page is overwhelmingly long runs of identical white pixels, which is close to ideal input for a dictionary compressor. Measured on a rendered test page, a 360 KB bitmap came out at roughly 2 KB inside the archive, about 99 percent, and extracted byte for byte identical. Real pages vary, but reductions above ninety percent are routine.
So the download stays small, the extracted bitmaps are full size and uncompressed, and the system consuming them gets exactly what it specified. The compression runs through the browser native Deflate implementation, and the result is a standard ZIP that any extractor opens, including the one built into Windows.
One safeguard is worth mentioning. If compression ever fails to make an entry smaller, the stored bytes are kept instead, because an archive should never grow as the result of an optimization.
The output is the most widely supported bitmap variant there is: 24 bit BI_RGB with a 40 byte BITMAPINFOHEADER. No palette, no bit fields, no run-length encoding, no alpha channel, no color management. That is deliberate. The reason to choose BMP in 2026 is that there is nothing left for two systems to disagree about, and adding anything optional would defeat the point of picking it.
This catches out anybody reading the pixel data by hand for the first time. When the height field is positive, the first row of pixel data in the file is the bottom row of the image. It is a convention inherited from the coordinate system of early graphics hardware, and every correct BMP reader expects it. Write the rows the other way round without also making the height negative and you get a file that displays upside down in some software and correctly in the rest, which is the worst of the available outcomes.
The info header carries horizontal and vertical resolution as pixels per meter. A great deal of software writes zero into both, which leaves the receiving system with no idea what physical size the image is meant to be. This converter writes the real value derived from the dpi you chose, so a page rendered at 300 dpi reports 11,811 pixels per meter and prints at its intended physical size instead of at whatever the consuming application decides to assume.
That single field is frequently the difference between a bitmap that drops into an industrial workflow correctly and one that arrives at the wrong scale.
For almost everybody reading this, PDF to PNG is the better tool. PNG is also lossless, gives pixel-identical results, comes out a fraction of the size, and is supported everywhere. If you are converting pages to look at, to publish, or to send to a person, use PNG and stop reading here.
BMP is correct when something specific requires it, and those situations are real:
The thread running through all of them is that some consumer downstream needs pixels with no decoder, no ambiguity and no dependency. BMP delivers exactly that, and the file size is what it costs.
No browser can write a BMP either. Ask a canvas for one and it silently returns PNG data with the wrong MIME type attached. The bitmaps here are assembled byte by byte in this page, which is why the header fields are correct rather than whatever a silent fallback happened to produce.
This matters more here than for most conversions, for a practical reason as well as a principled one. The documents people turn into bitmaps are inspection records, medical images, engineering drawings and production data, and the volumes involved are enormous.
There is no upload step. The JavaScript on this page reads your file through the browser File API, renders each page on your own processor, writes the bitmap bytes in this tab, and hands the result back through a temporary object URL. No server-side component takes part, so no copy of your document exists anywhere to be breached, retained past a stated window, subpoenaed, or found in an unsecured bucket in three years.
The practical benefit is just as concrete. A server-based converter would have to send half a gigabyte of bitmaps back down the wire after you had finished uploading the document to it. Doing the work locally means the bytes never move at all.
Thirty seconds to prove it. Open this page, turn off your Wi-Fi, drop in a PDF and convert. A tool that had to upload the document and return half a gigabyte would fail immediately. This one produces the bitmaps.
The only thing that reaches a server is the operation counter enforcing the free tier. It records that a conversion happened and when. It never receives your document, its name, its page count, or anything derived from its contents.
You can calculate it exactly, because BMP applies no compression. Take the width in pixels, multiply by three, round up to a multiple of four, multiply by the height, and add 54 bytes of headers. An A4 page at 150 dpi is about 6.5 MB, at 300 dpi about 26 MB, and at 600 dpi about 104 MB. Resolution applies in both directions, so each step up roughly quadruples the file.
Because the archive is genuinely compressed for this format, unlike the others in this suite. A bitmap is raw pixel data, and a rendered page is overwhelmingly long runs of identical white pixels, which compresses extremely well. On a rendered test page a 360 KB bitmap came out at roughly 2 KB inside the archive and extracted byte for byte identical. The files you extract are full size and uncompressed, exactly as the target system needs them.
PNG, unless something specific requires BMP. PNG is also lossless and gives pixel-identical results at a fraction of the size, and it is supported everywhere. Choose BMP when a legacy import filter, a machine vision system, an embedded display or a compliance rule specifies an uncompressed bitmap and will accept nothing else.
24 bit BI_RGB with a 40 byte BITMAPINFOHEADER, which is the most widely supported variant there is. No palette, no bit fields, no run-length encoding, no alpha and no color management, because the reason to choose BMP is that there is nothing left to disagree about. Rows run bottom to top with each row padded to a four byte boundary, which is the format default that every correct reader expects.
Yes, and properly. The info header carries horizontal and vertical resolution in pixels per meter, and this converter writes the real value derived from the dpi you selected, so a page rendered at 300 dpi reports 11,811 pixels per meter. A great deal of software writes zero there and leaves the receiving system guessing at the physical size, which is often the difference between a bitmap that drops into an industrial workflow correctly and one that arrives at the wrong scale.
No. The file is read by JavaScript in your browser, rendered on your own processor, and the bitmap bytes are written in this tab. Nothing is transmitted, which matters for confidentiality and practically too, since a server-based converter would have to send half a gigabyte back down the wire. Confirm it by disconnecting from the internet and converting anyway.
Because the job would not fit in the memory of your browser tab. Bitmaps hit that ceiling faster than any other format here, since a 300 dpi A4 page is 8.7 million pixels and about 26 MB before the render buffer is even counted, and the budget across a whole run is 900 million output pixels. The total is checked before any work starts, so a refusal costs you nothing, whereas attempting it would freeze the tab and consume the operation anyway.
Yes, and with this format you almost always should. Type a range into the Pages field the way you would in a print dialog: 1-5, or 2,7,11-14. Ranges written backwards are normalized for you, and an open ended 8- means from page eight to the end. Converting a whole document at 300 dpi produces gigabytes for anything longer than a few pages.
Completely. Every byte in the file maps directly to one color channel of one pixel, with no transform and no quantization anywhere in the chain. The only loss is the one you control: rendering a resolution-independent page description down onto a fixed pixel grid at the dpi you chose.
No. The variant written here has no alpha channel, and a PDF page has no background object of its own in any case, so every page is rendered onto white first. Without that, a page carrying white text on a dark fill would produce an image that looks completely blank the moment it is placed on white.
Because no browser can encode BMP. Ask a canvas for one and it silently returns PNG data labeled with the wrong MIME type and raises no error at all, so a converter that trusted the browser would hand you PNG files named .bmp. That passes unnoticed until the file reaches something that reads headers rather than extensions, which is precisely the legacy system the bitmap was needed for.
No. Nothing is stamped on the output, no logo is added, no trial banner appears and no attribution is required. The images contain your pages and nothing else, and they are free for commercial use.
It runs, but it is the least suitable of the six formats for a phone. Bitmaps are enormous, a phone tab has far less memory headroom than a desktop one, and the refusal threshold arrives quickly. If you need bitmaps, use a desktop machine.
Not for your first operation. One conversion run counts as one operation regardless of how many pages it produced. Anonymous visitors get one per 12 hours counted by network address, a free account gets two, and Premium removes the counter and raises the batch ceiling from 20 files or 100 MB to 100 files or 500 MB, which for this format is the limit that actually binds.
All of these run the same way: your file is read by JavaScript on your own machine, the work happens on your processor, and the result is handed back to you as a download that never existed anywhere else.
Find the apps that slow your store down, by name and in milliseconds, then answer shoppers' doubts with trust badges under Add to cart. Both are free, with no card and no access to your store admin.
Paste any page and get its three Core Web Vitals, the apps costing time, like Klaviyo or Judge.me, and the Shopify or WooCommerce fix.
Show the promises that settle doubts, from free shipping to a money-back guarantee, right under the Add to cart button. One line in your theme.
Change the link after printing and count the scans. 5 tracked codes on a free account, static codes unlimited.
Anonymous visitors get one operation per 12 hours, per network address. That is not a sales tactic, it is the only lever we have: this tool runs on your processor, not ours, so the run itself earns us nothing. An account tells us who you are, and the ceiling goes up the moment you have one. Your allowance resets in 12 h.
No credit card, no trial period, no sales call. Join with Google, GitHub, Facebook or email.
Free accounts get two operations per 12 hours, and yours reset in 12 h. Waiting costs you nothing and is a completely reasonable choice. If PDF work is a weekly job rather than a one-off, the counter is the wrong tool for you and Premium takes it off the page.
Cancel anytime. Everything you have already produced stays yours either way.