Initializing... drag & drop files here
Supports: BMP
BMP (Windows Bitmap) is Microsoft's uncompressed raster format, introduced with Windows 1.0 in November 1985 and formalized alongside Windows 2.0 in 1987. Because 24-bit BMP stores three raw bytes per pixel with no entropy coding, a single 1920x1080 screenshot weighs roughly 5.9 MB (1920 x 1080 x 3 = 6,220,800 bytes), and a 4K capture pushes past 23 MB. A folder of those bitmaps is painful to email, link, or archive. Wrapping them in a PDF (ISO 32000, standardized by ISO in July 2008) gives you one portable file that opens identically on Windows, macOS, iOS, Android, and any modern browser, with the embedded images JPEG-compressed at the quality you choose.
| Property | BMP | PDF (with embedded BMP pages) |
|---|---|---|
| Format type | Raster image (single bitmap) | Document container (multi-page) |
| Standardized by | Microsoft (Windows 1.0, 1985; spec with Windows 2.0, 1987) | ISO 32000-1:2008 (PDF 1.7); ISO 32000-2:2020 (PDF 2.0) |
| Compression | None for 16/24/32 bpp; optional RLE for 4/8 bpp; Huffman 1D for monochrome | Per-image: JPEG (lossy), Flate/Deflate, JBIG2, JPEG2000 |
| Color depth | 1, 2, 4, 8, 16, 24, 32 bpp (GDI+ also 64 bpp) | 24-bit color images at chosen quality; 1-bit for line art |
| Multi-page | No (one image per file) | Yes (native pagination) |
| File size (1920x1080, 24-bit) | ~5.9 MB raw | ~150-700 KB per page at Quality 75 |
| Transparency | 32-bit BMP supports alpha; rarely honored by viewers | Honored if preserved; can be flattened to white |
| Universal viewers | Windows native; partial elsewhere | Every modern browser, OS, and reader |
| Best for | Lossless pixel exchange between Windows tools | Distribution, archival, e-filing, email |
| Quality | Visual result | Typical 1920x1080 page size | Best for |
|---|---|---|---|
| 30-50 | Visible JPEG artifacts on gradients and text edges | 60-150 KB | Email-only previews, internal review |
| 60-75 (default 75) | Clean for screenshots and scans; mild softening on photos | 150-400 KB | General sharing, the "right answer" most of the time |
| 80-90 | Indistinguishable from source on monitors | 400-900 KB | Client deliverables, printed handouts |
| 95-100 | Near-lossless; large PDFs | 900 KB-2 MB+ | Archival, medical/scientific, prepress |
Usually 70-95 percent smaller. A 24-bit 1920x1080 BMP is about 5.9 MB raw because every pixel is stored as three uncompressed bytes (1920 x 1080 x 3 = 6,220,800 bytes). The same image embedded in a PDF at Image Quality 75 typically lands at 150-400 KB — it's re-encoded with JPEG inside the document. Screenshots of dialog boxes and text compress even harder; photo-heavy bitmaps compress less.
No, not at the default settings. The Image Quality slider re-encodes embedded images as JPEG, which is lossy. If you need pixel-exact preservation of the original BMP, push Quality to 95-100 (still technically lossy, but visually indistinguishable on a monitor) or convert each BMP to PNG first with BMP to PNG and then merge — PNG inside PDF uses Flate compression and is fully lossless.
Use Contained (default) when your bitmaps have varied aspect ratios — screenshots, scanned forms, and CAD plots — so the whole image always fits inside the page with safe margins. Use Cover when every BMP shares the same aspect ratio as the chosen Paper size (for example, 16:9 screenshots on a Landscape page) and you want edge-to-edge output with no white border. Cover will crop anything that doesn't match the page ratio.
Selecting Original (which maps to "same as image size" internally) makes each PDF page exactly the pixel dimensions of the BMP it wraps, so a 3000x2000 scan becomes a 3000x2000-point page. That's ideal when you don't want any letterboxing, cropping, or rescaling — common for archival scans, comic-page workflows, and pixel-art collections. The downside is that page sizes vary across the document, which some printers handle poorly.
32-bit BMP can store an alpha channel (8 bits per pixel for transparency). Most BMPs in the wild are 24-bit and have no alpha, so this setting has no effect. For 32-bit BMPs with transparency, "Removed" composites the image onto a white background before embedding, which prevents PDF viewers that don't support image transparency from rendering grey or black behind the alpha pixels. Leave it on Unchanged if you're not sure.
Not on this page — merge-bmp-to-pdf only accepts .bmp inputs. If you have a mix, convert your other images to BMP first, or use Merge JPG to PDF or Merge PNG to PDF for those source formats. A future enhancement could allow mixed inputs through the generic image-merge endpoint, but today the page is type-locked.
Browser-based processing means the practical limit is your device's RAM, not a server quota. Most users can merge 50-150 BMPs comfortably on a modern laptop. If you're combining hundreds of high-resolution scans (300+ MB of input), close other tabs first, or split the job into two batches and concatenate the resulting PDFs afterward.
Two common causes: (1) you set Image Quality to 95-100, which keeps the JPEG re-encode near-lossless and produces large pages — drop to 75 for a typical 5-10x size reduction; (2) your BMPs are very high-resolution scans (4800 DPI or 4K-plus dimensions) and even compressed JPEG pages are ~1-2 MB each. For a slimmer file, compress the merged PDF afterward, or downscale the BMPs first with Compress BMP.
The merged PDF does not copy the BMP's embedded ICC profile by default — embedded images are re-encoded into a generic sRGB-tagged JPEG. For prepress or color-critical work where ICC fidelity matters, use Compression Type "Prepress" if exposed, keep Quality at 95+, and verify the output in a calibrated viewer. For most office, web, and screenshot use cases, the default sRGB pipeline is correct and indistinguishable from the source.