.JPEG JPEG Image
.jpeg

JPEG Image

Convert JPEG images to PNG, WebP, or BMP directly in your browser — no upload, no server, no quality loss beyond the original JPEG compression. FileDex processes your images locally using WebAssembly. The .jpeg extension is identical to .jpg — same format, same compression, same file structure.

Learn more ↓
Image structure
Header signature
Meta dimensions · color
Pixels image data
Lossy ImageDCT Compression8-bit ColorEXIF / XMP1992
By FileDex

Your files never leave your device

Common questions

What is the difference between JPEG and JPG?

There is no difference. JPEG and JPG are the same format with the same compression, same file structure, and same MIME type (image/jpeg). The .jpg extension exists because early Windows versions (3.1, 95) required three-character file extensions. Modern systems accept both interchangeably.

Does converting JPEG to PNG improve image quality?

No. Converting JPEG to PNG does not restore pixel data discarded during JPEG compression. The PNG file will be larger but contain identical visual content. PNG conversion is useful when you need lossless storage of the already-decoded pixels or require transparency support.

How do I reduce JPEG file size without visible quality loss?

Use jpegtran -optimize -progressive for lossless file size reduction (typically 5-15% savings). For further reduction, re-encode at quality 80-85 — this is the threshold where most viewers cannot distinguish the output from the original in side-by-side comparison.

Why does my JPEG photo appear rotated in some applications?

The camera stored the correct orientation in the EXIF metadata (orientation tag), but some applications ignore this tag and display the raw pixel data. Run exiftool -auto-rotate input.jpeg to apply the EXIF rotation to the actual pixel data, then strip the orientation tag.

Can JPEG files contain viruses or malware?

Standard JPEG image data cannot execute code. However, crafted JPEG files have historically exploited parser vulnerabilities in image decoders (e.g., buffer overflows in libjpeg or GDI+). Modern browsers and OS image decoders are hardened against these attacks with sandboxing and bounds checking.

What makes .JPEG special

Joint Photographic Experts Group published this standard in 1992, and it still accounts for roughly 77% of all images on the web according to HTTP Archive's 2025 crawl data. That dominance is not inertia — JPEG's lossy compression hits a practical sweet spot between file size, decode speed, and visual quality that newer formats struggle to fully displace in every scenario.

Continue reading — full technical deep dive

Compression pipeline

JPEG encoding runs through four stages. First, the image converts from RGB to YCbCr color space, separating luminance (Y) from chrominance (Cb, Cr). Human vision resolves brightness at higher spatial frequency than color, so chrominance channels are typically downsampled 2:1 horizontally (4:2:2) or both horizontally and vertically (4:2:0), halving or quartering the color data before any math begins.

Second, each channel splits into 8×8 pixel blocks. Third, each block passes through the Discrete Cosine Transform, converting spatial pixel values into 64 frequency coefficients. The DC coefficient represents the block's average brightness; the remaining 63 AC coefficients capture increasingly fine detail.

Fourth, a quantization matrix divides each coefficient and rounds to the nearest integer. This is where data is destroyed. High-frequency coefficients get divided by large values, pushing them to zero. The quality slider in any image editor controls how aggressive this quantization is. At quality 85, a typical photograph retains visually indistinguishable output. Below 50, block artifacts emerge.

The 8×8 block boundary problem

JPEG's DCT operates on 8×8 pixel blocks independently, creating visible grid artifacts under heavy compression — the block size was chosen in 1992 as a balance between efficiency and consumer hardware processing power. Each block encodes with no awareness of its neighbors. At low quality, adjacent blocks quantize differently, producing a tiled checkerboard visible on smooth gradients. Modern decoders in Chrome and Safari apply post-processing deblocking filters, but the artifact is baked into the bitstream.

Performance benchmarks

Quality Compression ratio Typical 12 MP photo SSIM vs original
95 8:1 4.5 MB 0.99
85 15:1 2.4 MB 0.97
70 25:1 1.4 MB 0.94
40 50:1 0.7 MB 0.87

Decode speed is JPEG's hidden advantage. libjpeg-turbo, the standard decoder on Linux and Android, processes a 12 MP image in 25–40 ms using SIMD-accelerated IDCT. WebP decode runs 1.3–2× slower for equivalent dimensions. AVIF decode is 3–5× slower. On low-power mobile devices, that gap matters for scroll performance.

Progressive vs baseline

Baseline JPEG encodes blocks left-to-right, top-to-bottom in a single scan. Progressive JPEG stores multiple scans of increasing detail — the first scan renders a blurry full-frame preview in roughly 15% of the file, then subsequent scans sharpen it. Progressive files are 2–5% smaller than baseline at the same quality because the multi-scan layout allows more efficient Huffman coding of AC coefficients.

When to use JPEG vs alternatives

JPEG remains the best choice for photographs distributed to unknown clients — email attachments, CMS uploads, legacy device support. WebP offers 25–30% smaller files at equal quality and supports transparency, making it superior for web delivery when format negotiation is available. AVIF compresses 40–50% smaller but decodes slowly and lacks support in older Safari versions. PNG is the right choice only when lossless output or alpha transparency is required.

Limitations

No transparency. No animation (MJPEG wraps frames in AVI or MOV, not in JPEG itself). Maximum dimension is 65,535 pixels per side. Color depth caps at 8 bits per channel in standard JPEG; higher-bit workflows require JPEG 2000 or JPEG XL. And JPEG's patent-free status, settled after the Forgent Networks dispute in 2006, means no licensing cost — a practical advantage that helped cement its ubiquity.

.JPEG compared to alternatives

.JPEG compared to alternative formats
Formats Criteria Winner
.JPEG vs .PNG
File size for photographs
JPEG's DCT-based lossy compression produces files 5-10x smaller than PNG for photographic content. PNG's lossless compression cannot exploit the psychovisual redundancy that JPEG's quantization step removes.
JPEG wins
.JPEG vs .WEBP
Compression efficiency for photos
WebP lossy mode achieves 25-34% smaller files than JPEG at equivalent SSIM quality, using block prediction and adaptive quantization improvements over JPEG's fixed 8x8 DCT blocks.
WEBP wins
.JPEG vs .PNG
Transparency support
JPEG does not support alpha channels or transparency. PNG supports 8-bit alpha for per-pixel transparency and is required for images that need transparent backgrounds.
PNG wins
.JPEG vs .HEIC
Compression efficiency
HEIC uses HEVC intra-frame coding and achieves roughly 50% size reduction over JPEG at equivalent quality. HEIC is the default camera format on iOS since iPhone 7, but lacks universal browser support.
HEIC wins

Technical reference

MIME Type
image/jpeg
Magic Bytes
FF D8 FF JPEG SOI marker followed by marker type byte.
Developer
Joint Photographic Experts Group
Year Introduced
1992
Open Standard
Yes — View specification
00000000FFD8FF ...

JPEG SOI marker followed by marker type byte.

Binary Structure

JPEG files are structured as a sequence of marker segments. Every JPEG begins with the SOI (Start of Image) marker FF D8, immediately followed by one or more marker segments. Each marker starts with FF followed by a marker type byte. APP0 (FF E0) contains JFIF identification data; APP1 (FF E1) contains EXIF metadata with camera settings, GPS coordinates, and thumbnails. DQT (FF DB) defines quantization tables that control compression quality — lower values mean less quantization error and larger files. SOF0 (FF C0) indicates baseline DCT compression with image dimensions and component count; SOF2 (FF C2) indicates progressive encoding where the image loads in increasing detail passes. DHT (FF C4) defines Huffman coding tables. SOS (FF DA) marks the start of compressed scan data — the actual DCT-compressed image payload follows this marker with byte-stuffing (any natural FF in the data is followed by 00 to prevent false marker detection). The file ends with the EOI (End of Image) marker FF D9.

OffsetLengthFieldExampleDescription
0x00 2 bytes SOI Marker FF D8 Start of Image — every valid JPEG begins with these two bytes. No exceptions.
0x02 2 bytes APP0 or APP1 Marker FF E0 (JFIF) or FF E1 (EXIF) Application-specific marker. FF E0 = JFIF header with version and density. FF E1 = EXIF header with camera metadata, GPS, and thumbnail.
variable variable DQT Marker FF DB Define Quantization Table — specifies the 8x8 quantization matrix used during DCT compression. Quality setting directly controls these values.
variable variable SOF0 / SOF2 Marker FF C0 (baseline) or FF C2 (progressive) Start of Frame — contains image height, width, component count, and subsampling factors. SOF0 = sequential baseline, SOF2 = progressive.
variable variable SOS Marker FF DA Start of Scan — marks the beginning of compressed image data. All DCT-compressed pixel data follows this marker.
EOF-2 2 bytes EOI Marker FF D9 End of Image — every valid JPEG terminates with these two bytes.
1992JPEG standard published as ISO/IEC 10918-1 by the Joint Photographic Experts Group1994EXIF metadata specification introduced, enabling cameras to embed settings and GPS data in JPEG files1996Progressive JPEG (SOF2) adopted by web browsers, allowing images to load in increasing detail passes2000JPEG 2000 (ISO 15444-1) released as a wavelet-based successor, but fails to displace original JPEG2010Google introduces WebP as a JPEG alternative, offering 25-34% smaller files at equivalent quality2017EXIF 2.31 updates metadata specification with UTF-8 support and extended GPS precision2021JPEG XL (ISO 18181) published as a modern successor with lossless JPEG recompression capability
Convert JPEG to PNG (lossless output) ffmpeg
ffmpeg -i input.jpeg output.png

Decodes the JPEG and writes the pixel data to a PNG with lossless compression. The output preserves exactly the decoded JPEG pixel values — no further quality loss.

Convert JPEG to WebP at quality 80 other
cwebp -q 80 input.jpeg -o output.webp

cwebp is Google's WebP encoder. -q 80 sets lossy quality level (0-100). Quality 80 produces approximately 30% smaller files than the source JPEG with minimal visual difference.

Strip EXIF metadata from JPEG exiftool
exiftool -all= input.jpeg

Removes all metadata (EXIF, XMP, IPTC) from the JPEG file in-place. Useful for privacy — removes GPS coordinates, camera serial numbers, and editing history before sharing.

Optimize JPEG file size without re-encoding other
jpegtran -optimize -progressive -copy none -outfile output.jpeg input.jpeg

jpegtran performs lossless JPEG optimization by recomputing Huffman tables (-optimize), converting to progressive scan (-progressive), and stripping metadata (-copy none). No pixel data changes.

JPEG PNG transcode lossless PNG uses lossless compression, preserving the decoded JPEG pixel data without further quality loss. Required when downstream tools expect lossless input or when the image needs an alpha channel for transparency compositing.
JPEG WEBP transcode lossy WebP lossy mode produces 25-34% smaller files than JPEG at equivalent visual quality. WebP is supported in all modern browsers and is the preferred format for web performance optimization.
JPEG BMP transcode lossless BMP stores uncompressed pixel data, required by some legacy Windows applications, embedded systems firmware, and image processing pipelines that operate on raw bitmap data.
JPEG AVIF transcode lossy AVIF uses AV1 intra-frame coding to achieve 30-50% smaller files than JPEG at equivalent quality. Supported in Chrome, Firefox, and Safari 16+, AVIF is the next-generation web image format.
MEDIUM

Attack Vectors

  • Crafted DQT or DHT marker segments with oversized length fields can trigger heap buffer overflows in decoders that allocate memory based on declared marker length without bounds checking
  • Malformed EXIF data in the APP1 segment can exploit vulnerabilities in metadata parsers — historically used for remote code execution via crafted IFD entries
  • JPEG polyglot files embed executable content (HTML, JavaScript, PHP) after the EOI marker, exploiting web servers that serve user-uploaded JPEGs with incorrect MIME types
  • Progressive JPEG files with extreme scan counts can cause excessive memory allocation in decoders that buffer all scans before rendering

Mitigation: FileDex processes JPEG files entirely in-browser using WebAssembly sandboxed in a Web Worker. No file data leaves the device. Browser image decoders apply strict bounds checking and run in sandboxed renderer processes.

libjpeg-turbo library
High-performance JPEG codec using SIMD instructions, used by Chrome, Firefox, and most Linux distributions
ImageMagick tool
Command-line image processing suite with JPEG read/write, quality control, and batch conversion
ExifTool tool
Perl-based metadata reader/writer supporting EXIF, XMP, IPTC, and MakerNotes in JPEG files
MozJPEG library
Mozilla's optimized JPEG encoder producing 5-10% smaller files than libjpeg at identical quality
Pillow (PIL) library
Python imaging library with JPEG read/write, EXIF access, and quality-controlled save
sharp library
High-performance Node.js image processing library built on libvips with JPEG pipeline support