HEIC MIME Type – Free, Online, Private

What .heic is

Phones, especially iPhones, capture stills as HEIC. The file is a HEIF container whose brand is heic, with HEVC (H.265) samples inside. It starts like other ISOBMFF files: a size and ftyp. image/heic is the type for that brand. image/heif is the type for the more general HEIF brand and is not a synonym you should swap in without looking at the brand list. A .heic file is not a JPEG that was renamed. The bytes will not start with FF D8.

IANA registers image/heic. image/heif is the related type for the HEIF brand. The media type is image/heic. Extensions that use it on this page: .heic. A client compares the type, not the filename, once the response has arrived. The filename still matters on disk and in Content-Disposition, which is why a wrong extension and a wrong header are two different bugs.

What sends image/heic

What sends image/heic: Send image/heic when you are delivering the original phone photo to a client that can decode HEVC. Browsers have uneven support. A website that has to show the picture should transcode to JPEG, WebP, or AVIF and send that type on the preview URL. Keep the original at its own URL if you promised to store it. An upload endpoint should accept image/heic and also sniff ftyp, because mobile browsers sometimes post the file as application/octet-stream. The file on disk is still .heic. Once the response exists, a client trusts image/heic, not the filename. If you transcode for the web, write the derived file next to the original and give it a URL that ends in the format you actually produced. Cache the derived file. Do not transcode on every GET. The Content-Type of the derived file is the derived format's type, and the original response stays image/heic.

Content-Type for .heic

Send image/heic and do not add a charset parameter. The body is binary. A charset tells a text decoder to reinterpret bytes that are not text, which corrupts a download and does not help a browser sniff the format.

Content-TypeContent-Type: image/heic

nginx, Apache, and Express

These snippets map .heic to image/heic. nginx reads the types block when it picks a type from the URL's extension. A location that sets default_type, or an application that sets the header itself, overrides that map. Apache AddType applies in the directory context where you put it. The Express static example writes the header for files ending in .heic so a stale mime database in the framework cannot disagree with the type on this page.

nginx# /etc/nginx/mime.types, inside the types { } block
image/heic                  heic;

ApacheAddType image/heic .heic

Expressimport express from "express";

const app = express();
app.use(express.static("public", {
  setHeaders(res, filePath) {
    if (filePath.endsWith(".heic")) {
      res.setHeader("Content-Type", "image/heic");
    }
  },
}));

Pitfalls for image/heic

Pitfalls that show up for image/heic, and not for a neighboring type with a similar extension: The support incident is a user who attached a HEIC, the server stored it, and the web UI served it as image/jpeg because the converter was skipped. The image breaks. Detect the brand and convert, or serve image/heic and do not pretend. Another trap is stripping the HEVC payload while keeping the HEIF box structure, which leaves a file that is well typed and empty. A third is a licensing surprise: decoding HEVC is not universally available on servers. A failed decoder should be an error, not a 200 with a zero-byte body typed as image/jpeg.

• image/heic-sequence is for image sequences. A normal camera still is image/heic.
• HEIC can contain a depth map or a gain map in extra items. Naive conversion drops them. That is a product decision, not a header decision.
• Renaming .heic to .jpg does not change the codec. Check ftyp.
• Do not add a charset. The container is binary.