PicaJet

Reference Formats

JPEG

A lossy, DCT-based compression standard for photographic images that trades fine detail for very small file sizes, making it the default web and camera delivery format.

Extension

.jpg

Full name

Joint Photographic Experts Group

Introduced

1992 (ITU-T T.81); published as ISO/IEC 10918-1 in 1994

Vendor

ISO/IEC JTC 1 and ITU-T (Joint Photographic Experts Group)

What is inside the container

JPEG uses discrete cosine transform (DCT) compression in baseline or progressive mode, at 8 bits per channel with no alpha channel, typically in YCbCr color space. It is the best-supported format of any raster type for metadata: EXIF (APP1), IPTC-IIM (APP13), XMP (APP1) and ICC color profiles (APP2) can all be embedded simultaneously. Repeated editing and re-saving degrades image quality (generation loss) and can silently strip these metadata segments if the editing tool doesn't preserve them.

How to open it

macOS Preview and Quick Look (native, all versions)
Windows Photos app and Paint (native, all versions since Windows 3.0-era codecs)
Web browsers Every major browser since the 1990s renders JPEG natively
Cross-platform Photoshop, GIMP, ExifTool (full metadata read/write), and virtually all image software

For archives

Do not use JPEG as a DAM preservation master — its lossy compression means every re-save loses additional detail, and it was never designed for archival fidelity. Keep the original camera file, scan, or a lossless master (TIFF, JPEG 2000 lossless, or RAW) in the archive tier, and generate JPEG only as a derivative for thumbnails, web previews, and delivery copies.

JPEG was formalized in 1992 by the Joint Photographic Experts Group, a working group jointly convened by ISO/IEC and ITU-T, to solve a very specific late-1980s problem: photographic images were too large to store or transmit affordably. Its DCT-based lossy compression made continuous-tone photography practical on the early web and on the first consumer digital cameras, and it remains the most widely decodable image format ever created — every browser, OS, and image tool since the 1990s reads it natively.

For a DAM, JPEG’s importance is almost entirely on the delivery side, not the archival side. Because it carries EXIF, IPTC, and XMP simultaneously and supports embedded ICC profiles, it is often the richest metadata source a DAM ingests — camera-generated EXIF (capture date, lens, exposure) arrives intact on nearly every JPEG upload, which is why JPEG is usually the easiest format to auto-populate search fields from. Thumbnail and preview-rendering pipelines in almost every DAM render out to JPEG by default, since decoding cost is low and compatibility is universal.

The pitfall for DAM operators is treating JPEG as safe to edit in place. Cropping, color-correcting, or re-compressing a JPEG inside a workflow tool that doesn’t preserve APP metadata segments can silently strip EXIF/IPTC/XMP — a common cause of DAM assets that “lost their metadata” after a routine edit. A well-run DAM either locks JPEG masters as read-only or routes any edit through a tool with verified metadata round-tripping, and keeps the true archival master in a lossless format.

Frequently asked

Is JPEG suitable as a DAM archival master file?

No. JPEG's lossy DCT compression causes generation loss on every re-save, so it was never designed for archival fidelity. Keep a lossless master such as TIFF, JPEG 2000 lossless, or the original RAW file, and generate JPEG only as a delivery derivative.

What metadata can a JPEG file carry?

JPEG can embed EXIF (APP1), IPTC-IIM (APP13), XMP (APP1), and ICC color profiles (APP2) all at once. That makes it the best-supported format of any raster type for simultaneous metadata, and often the richest metadata source a DAM ingests.

Why does a JPEG sometimes lose its metadata after editing?

Cropping, color-correcting, or re-compressing a JPEG in a tool that doesn't preserve APP marker segments can silently strip EXIF, IPTC, and XMP. A well-run DAM either locks JPEG masters as read-only or routes edits through tools with verified metadata round-tripping.

Why is JPEG the default format for DAM thumbnails and previews?

Its decoding cost is low and its compatibility is universal — every browser, OS, and image tool since the 1990s renders JPEG natively — which makes it the practical default for preview-rendering pipelines.

Does JPEG support transparency or an alpha channel?

No. JPEG has no alpha channel support at all, which is one reason DAM systems reach for PNG or WebP instead when a graphic needs transparency.

Can a DAM auto-populate search fields from JPEG uploads?

Yes, usually more reliably than from other formats. Camera-generated EXIF — capture date, lens, exposure — arrives intact on nearly every JPEG upload, which is why JPEG is typically the easiest format to auto-index on ingest.

What compression method does JPEG use?

JPEG uses discrete cosine transform (DCT) compression in baseline or progressive mode, at 8 bits per channel with no alpha channel, typically stored in YCbCr color space.

How should a DAM handle repeated edits to a JPEG asset?

Avoid editing JPEG masters in place. Because compression is lossy, every re-save degrades quality further, so any workflow that needs repeated edits should work from a lossless master and export JPEG only as the final derivative.

Sources

  • JPEG was standardized as ITU-T Recommendation T.81 in 1992 and published as ISO/IEC 10918-1 in 1994 by the Joint Photographic Experts Group. checked 2026-08-07ANSI Blog: The JPEG Standard
  • JPEG files can carry EXIF, IPTC-IIM, and XMP metadata in separate APP marker segments. checked 2026-08-07Exiv2: The Metadata in JPEG files
  • Lossy formats like JPEG are not recommended as archival master files for digitization projects. checked 2026-08-07FADGI Raster Format Comparison