Transforms & Editorial Configuration

Transforms

Every delivered image goes through one transform endpoint; with no parameters at all, the original uploaded file is served unmodified.

Parameter	Values	Notes
`width` / `height`	1–5000px	Clamped server-side at 5000px
`format`	`auto \| webp \| avif \| jpeg \| jpg \| png \| gif`	`auto` content-negotiates avif → webp → jpeg based on the requesting browser
`quality`	1–100	Default 85
`fit`	`scale-down \| contain \| pad \| squeeze \| cover \| crop \| aspect-crop`	How the image fits into width/height
`gravity`	`face \| left \| right \| top \| bottom \| center \| auto \| entropy`, or coordinates like `0.3x0.7`	Focal point for cropping fits
`blur`	0–250
`brightness` / `contrast` / `saturation`	0–10
`sharpen`	0–10
`rotate`	0 \| 90 \| 180 \| 270
`trim.top` / `trim.left` / `trim.width` / `trim.height`	source pixels	Manual crop rectangle

Two layers apply these: crop intent (Fit in / Smart crop / a manual custom crop) is set once by an editor and baked into the stored value; delivery sizing (width/height/format/quality, via buildImageUrl() or a component’s transform option) merges on top per-component without disturbing the crop already chosen.

format specifically has no default outside one helper; see Requirements before assuming WebP/AVIF delivery happens automatically.

What’s editorially fixed vs. configurable

The crop/transform options an editor actually sees are hardcoded in the plugin’s UI today; not configurable per site or per component.

Crop mode choices (Fit in / Smart crop / Custom on rich fields, Fit in / Smart crop on basic fields) are fixed; no adding, removing, or relabeling them.
Aspect-ratio presets in the custom-crop dialog (Free, 1:1, 4:3, 3:2, 16:9) are a fixed list.
No focal-point/gravity picker in the editor, even though the delivery endpoint itself supports named and coordinate-based gravity (see table above). The only gravity value the editor UI ever produces is gravity=auto, via “Smart crop.” The backend’s capability is broader than anything an editor can currently choose.
Metadata field values are limited to four fixed names platform-wide: alt, caption, credit, byline. You can choose which of these four to show and in what order (the schema option), but you can’t add a custom metadata field name (e.g. “photographer”) yet.

What is configurable: which field names trigger basic-mode picking (fieldNamePatterns), the delivered size/format per component (transform), and which of the four metadata fields appear.