jekcms converts uploads to AVIF and WebP automatically and generates seven size variants per image. Here's what the pipeline actually does — and what it doesn't, like face-aware cropping or a live resizing proxy, neither of which exist.
When a file arrives at the upload endpoint, JekCMS first checks its dimensions and scales down oversized images before any format conversion takes place, keeping the encoder's input to a sane size and avoiding unexpectedly large output files.
EXIF Stripping and Secure Storage
EXIF stripping uses the GD or Imagick extension, depending on which is available on the server. All metadata is removed before the converted file is written to disk — GPS coordinates, camera model, creation timestamps, and any embedded thumbnails. The original file is stored under the uploads directory under a generated filename; the web server configuration blocks direct access to internal paths by default.
Seven Thumbnail Sizes and Fixed Quality Settings
jekcms generates seven named size variants at upload time: thumbnail (150×150, centre crop), small (300×200, crop), medium (600×400, crop), large (1200×800, no crop), full (1920×1280, no crop), pinterest (1000×1500, crop), and og (1200×630, crop for social share previews). Cropped variants use a plain centre crop — there's no face-detection step, so composition around a face or subject in a non-centred position isn't preserved automatically in a cropped size. The AVIF quality setting is 60 and WebP is 82, chosen for a strong size/quality balance; both are fixed in code rather than exposed as a settings-page option.
Serving Images in Custom Themes
In built-in themes, images are served via the <picture> element with AVIF as the primary source and WebP as the fallback. If you are building a custom theme, use the get_featured_image($post, 'medium') helper — it returns the correct source URL and handles the case where a specific sized variant wasn't generated for an image, by falling back through AVIF, then WebP, then the original file.
The Pipeline: Step by Step
The entire image processing pipeline executes during the upload request. Here is the sequence of operations from the moment a file reaches the server to the point where it is ready to serve:
1. Upload received -> validate MIME type
2. Check file size -> reject if too large (configurable limit)
3. Read dimensions -> scale down oversized originals
4. Strip EXIF metadata -> remove GPS, camera info, timestamps
5. Generate AVIF (quality 60) -> primary serving format
6. Generate WebP (quality 82) -> fallback format
7. Generate 7 sized variants (each in AVIF + WebP where applicable):
thumbnail, small, medium, large, full, pinterest, og
8. Store original file
9. Store converted files under the uploads directory
10. Write database record -> media table with all pathsRoughly How Much Smaller
The exact savings depend heavily on the source image — a busy photograph compresses differently than a flat-colour graphic — but AVIF and WebP both produce meaningfully smaller files than an equivalent-quality JPEG or PNG at the quality settings jekcms uses, which is the entire point of converting in the first place. If you want numbers specific to your own media library, compare a handful of your actual images before and after rather than relying on a single published percentage that may not reflect your content.
Falling Back When a Size Variant Is Missing
When a specific sized variant doesn't exist on disk for a given image — for example, an image uploaded before a size was added to the configuration — get_featured_image() doesn't generate one on the fly. It falls back through the format cascade instead (AVIF → WebP → original), serving whichever file actually exists rather than resizing on demand.
Batch-Converting Existing Images
jekcms's Media class includes a batchConvert() method that processes existing images in batches of 50, generating AVIF/WebP versions for images that don't have them yet. It's a real, working code path — if you're scripting a one-time backfill for a library that predates AVIF support on your install, this is what to reach for. There isn't currently a dedicated admin-panel screen with a live progress bar wired up to it; running it is a developer-level task, not a self-service settings-page button.
Browser Support and Content Negotiation
AVIF is supported by all current major browsers; for anything older or without AVIF support, the <picture> element provides automatic fallback to WebP and then the original format. JekCMS does not use server-side content negotiation (Accept header inspection) — the decision happens entirely in the browser via the <source> element's type attribute. This keeps the implementation simple and fully compatible with CDNs that do not forward the Accept header.
<picture>
<source srcset="/uploads/images/photo.avif" type="image/avif">
<source srcset="/uploads/images/photo.webp" type="image/webp">
<img src="/uploads/images/photo.jpg" alt="Description"
width="800" height="500" loading="lazy">
</picture>Handling Animated and Transparent Images
The pipeline treats animated GIFs and transparent PNGs as special cases. Animated GIFs are converted to WebP only, because AVIF animation support remains inconsistent across browsers.
The original GIF is preserved alongside the WebP version so that email clients and older platforms can still display the animation. Transparent PNGs are converted to both AVIF and WebP with alpha channel preservation enabled, ensuring that logos, icons, and overlay graphics retain their transparency after conversion.
