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.
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
| 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 |
Convert .JPEG to...
Technical reference
- MIME Type
image/jpeg- Magic Bytes
FF D8 FFJPEG SOI marker followed by marker type byte.- Developer
- Joint Photographic Experts Group
- Year Introduced
- 1992
- Open Standard
- Yes — View specification
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.
| Offset | Length | Field | Example | Description |
|---|---|---|---|---|
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. |
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.