Initializing... drag & drop files here
Supports: BMP
A Windows bitmap stores every pixel literally: three bytes per pixel for a 24-bit image, no compression, no cleverness. HEIF is the opposite end of the scale — it wraps an HEVC-coded still image in an ISO base media container (ISO/IEC 23008-12). Going from one to the other is the single biggest size reduction available for a plain BMP, and the only real question is what you give up for it. This page answers that with measurements rather than adjectives, and is honest about the one thing HEIF is genuinely bad at: being opened by anything other than Apple software.
A 1920 × 1080 24-bit BMP is 1920 × 1080 × 3 = 6,220,800 bytes of pixel data before the header — the size is fixed by the dimensions, not by the picture. We converted one such file (6,220,938 bytes on disk) at every rung of the Quality Preset dropdown:
| Quality Preset | Encoder quality | HEIF size | Smaller by |
|---|---|---|---|
| Highest | 100 | 837,040 bytes | 7.4× |
| Very High (opens here) | 95 | 837,040 bytes | 7.4× |
| High | 90 | 678,677 bytes | 9.2× |
| Medium | 80 | 286,146 bytes | 21.7× |
| Low | 70 | 158,245 bytes | 39.3× |
| Very Low | 60 | 96,849 bytes | 64.2× |
| Lowest | 50 | 51,292 bytes | 121× |
The interesting row is the first one. Highest and Very High produce the same encode: both landed on 837,040 bytes and the two files differed in only 36 bytes out of 837,040, all of them inside the codec parameter block rather than the picture. Choosing Highest over Very High for a HEIF output costs you nothing and gains you nothing. The genuine decisions live between High, Medium and Low.
.bmp onto the page or click "+ Add Files"; queue as many as you like and they are all converted with the same settings. Files are uploaded over an encrypted connection, processed on our servers, and deleted automatically after a few hours — no sign-up, no watermark, never shared or made public.Both .heif and .heic come out of the same encoder here, and the result is not ambiguous about what it contains:
| Property | Value in the output |
|---|---|
| Standard | HEIF, ISO/IEC 23008-12 |
| Major brand | heic — HEVC still image |
| Compatible brands | mif1, heic, miaf |
| Image codec | HEVC (H.265) |
| Bit depth written | 8 bits per channel |
| Alpha channel | Preserved from a 32-bit BMP; absent from a 24-bit one |
Relationship to .heic |
Byte-identical — we produced both and they matched on MD5 |
That last row is worth internalising. BMP to HEIC does not produce a different or more Apple-friendly file; it produces the same bytes under a different extension. Pick whichever name the software you are feeding expects. If you want a genuinely different — and much smaller — file, BMP to AVIF encodes with AV1 instead: on the same source at the same quality setting it came out at 242,827 bytes against HEIF's 837,040, about 3.4× smaller again.
This is HEIF's weak point and it has not improved. Per caniuse, global browser support for HEIF/HEIC sits at 15.02 %, and the entire figure comes from Safari 17.0 and later on macOS and iOS. Chrome, Firefox and Edge do not decode it in an <img> tag in any shipped version, and the licensing cost of HEVC is the reason rather than an oversight. Recent Windows can open HEIC files once the HEVC extension is installed; Android's support depends on the device.
If the destination is a web page, HEIF is the wrong choice and AVIF or WebP is the right one. If the destination is an Apple photo library, an iOS app, or a storage archive you control, HEIF's compression is exactly what you came for.
Yes. A BMP written with a v4 or v5 header and 32 bits per pixel carries a real alpha channel, and HEIF can store one. We converted a 32-bit BMP whose corners were fully transparent and read the output back as four-channel sRGBA with those corners still at zero alpha. A plain 24-bit BMP has no alpha to begin with, so its HEIF output is three-channel — nothing is lost, because there was nothing there.
Because BMP does not compress. A 24-bit bitmap spends exactly three bytes on every pixel regardless of content, so the file size is a pure function of width × height — 6.2 MB for 1080p, 24.9 MB for 4K, and the same whether the image is a photograph or a blank white rectangle. Run-length encoding exists in the BMP spec for 4-bit and 8-bit palette images, but almost nothing writes it and it does not apply to full-colour bitmaps.
No. Every rung of the Quality Preset dropdown, Highest included, runs a lossy HEVC encode — and on our test image Highest and Very High produced the same 837,040-byte file, which tells you Highest is not reaching for a lossless mode. If you need pixel-exact preservation of a bitmap, PNG is the format to convert to; if you need small, HEIF at High or Medium is doing its job well.
Whichever your destination software asks for, because the bytes are the same. .heic is the name Apple uses for HEVC-coded HEIF and is what an iPhone writes; .heif is the format's own generic name and is what you use when the file might hold something other than HEVC. Our output declares the heic brand either way, so an application that sniffs the container rather than the filename will treat both identically.
Because the encoder's quality-to-CRF mapping is quantised — several adjacent quality values land on the same internal setting, so the curve is a staircase rather than a smooth line. On our 1920 × 1080 test the values from 94 upward all produced 837,040 bytes, while 92 and 93 shared a different figure. If a preset does not move the size, the next rung down will.
Yes — queue them all and they convert with the same Quality Preset and resolution settings, each producing its own .heif. This is where the conversion earns its keep, because BMP archives are usually large for uninteresting reasons: screen captures, scanned output and old Windows assets that were never compressed. The real constraint is upload size and time rather than the number of files.
It should not, in any way you can see. BMP has no colour management to speak of — the pixels are plain sRGB values — and the HEIF output is written as 8-bit sRGB, so no profile conversion is involved. What HEVC does do at lower quality settings is reduce colour detail before it reduces brightness detail, which shows up first on saturated edges. That is a compression artefact rather than a colour shift, and Medium or above avoids it on normal images.
Usually yes, and by a lot, because halving both dimensions removes three quarters of the pixels before the encoder ever sees them. The Image resolution group gives you a percentage slider, height presets and explicit dimensions. A sensible order of operations is to size the image for its destination first, then choose the lowest Quality Preset that still looks right at that size — rather than encoding a 4K frame at Lowest and wondering why it looks smeared.