🐛 BUG: Local Images binding ignores EXIF orientation - photos render sideways in local dev

[vdanielb]

Which Cloudflare product(s) does this pertain to?

Miniflare

What versions are you using?

miniflare 4.20260730.0 (also present on main at time of filing)

What operating system and version are you using?

Windows 11 (reproduces on all platforms)

Describe the Bug

Observed behavior

The local (low-fidelity) Images binding polyfill does not apply EXIF orientation before transforming. Photos taken on phones (commonly stored as landscape pixels + EXIF Orientation: 6) come back sideways from env.IMAGES.input(...).transform(...) in local dev.

In production, the Images binding auto-applies EXIF orientation before transforms, so the same code produces upright images when deployed. This is a local/production fidelity gap that makes phone photos appear rotated 90° only in local dev.

Related: #14795 fixed the fit/gravity/background handling in the same code path (thanks!). Before that fix this bug presented as sideways + black letterbox bars; after it, images are still sideways.

Where it happens

In packages/miniflare/src/plugins/images/fetcher.ts, both local fetchers construct sharp without EXIF auto-orientation:

• imagesLocalFetcher: const transformer = sharp(await body.arrayBuffer(), {});
• cfImageLocalFetcher: const transformer = sharp(source);

runTransform only applies an explicit transform.rotate value; a parameterless EXIF-based rotation is never applied.

Expected behavior

The local binding should match production and orient images per their EXIF flag before applying user transforms. Since miniflare already depends on sharp 0.35.x, this is a one-line-per-fetcher fix:

sharp(await body.arrayBuffer(), { autoOrient: true })

(autoOrient bakes the EXIF rotation into pixels at decode and clears the orientation flag; an explicit user rotate then composes on top with production-matching semantics.)

Downstream impact

Any framework whose dev server routes image optimization through the local binding shows user photos sideways in dev but correct in production. Concretely: Astro's @astrojs/cloudflare adapter serves /_image through env.IMAGES in astro dev, so any EXIF-rotated photo renders sideways locally — this is how I found the bug.

Please provide a link to a minimal reproduction

See steps below — the repro is a few lines in any Worker with an images binding.

Steps to reproduce

1. Create a Worker with an images binding and this handler:

export default {
  async fetch(request, env) {
    const src = await fetch("https://github.com/recurser/exif-orientation-examples/raw/master/Portrait_6.jpg");
    const result = await env.IMAGES.input(src.body)
      .transform({ width: 300 })
      .output({ format: "image/jpeg" });
    return result.response();
  },
};

2. wrangler dev (local): the image is sideways.
3. wrangler dev --remote or deploy: the image is upright.

Please provide any relevant error logs

No errors are logged; the transform succeeds but produces incorrectly oriented output.

[workers-devprod]

Note

This is an automated, advisory triage report generated by workers-devprod. It is not an official maintainer response — a maintainer will follow up.

🤖 Automated triage report

Issue Triage: #15029

Summary

Miniflare's local (low-fidelity) Images binding does not apply EXIF orientation before transforming, so EXIF-rotated phone photos render sideways in local dev while appearing upright in production.

Classification

• Type: Bug
• Component: packages/miniflare
• Severity: Medium
• Has Reproduction: Yes (inline steps + public test image + Worker code)
• Quality: Complete

Findings

• Created: 2026-08-05
• Author: vdanielb
• Version: miniflare 4.20260730.0 (also reproduces on main)
• Labels: none
• Comments: 0

Analysis

• Well-scoped, high-quality report. The reporter pinpoints the exact source file (packages/miniflare/src/plugins/images/fetcher.ts) and the two call sites — imagesLocalFetcher (sharp(await body.arrayBuffer(), {})) and cfImageLocalFetcher (sharp(source)) — that construct sharp without EXIF auto-orientation, and notes that runTransform only applies an explicit transform.rotate.
• Clear local/production fidelity gap. Production auto-applies EXIF orientation before transforms; local does not. Same code, different output — exactly the class of bug Miniflare aims to avoid.
• Reproducible. Includes a minimal Worker handler, a public EXIF-rotated test image (exif-orientation-examples/Portrait_6.jpg), and clear steps: local wrangler dev is sideways, --remote/deploy is upright. Downstream impact called out via Astro's @astrojs/cloudflare adapter (/_image through env.IMAGES).
• Proposed fix is small and plausible. Reporter suggests constructing sharp with { autoOrient: true } in both fetchers, which bakes EXIF rotation into pixels at decode and clears the flag, letting an explicit user rotate compose on top. Miniflare already depends on sharp 0.35.x, so no new dependency is needed.
• Related to prior work. References [miniflare] Honour fit, gravity and background in the local Images binding #14795, which fixed fit/gravity/background in the same code path; this is a remaining orientation gap in that path.

Recommendation

Status: KEEP OPEN

Reasoning: This is a clear, reproducible correctness/fidelity bug in Miniflare's Images binding polyfill, with a well-identified root cause and a small proposed fix. It does not match any closeable category and is a good candidate for a quick fix.

Action: Confirm the autoOrient behavior against production semantics, apply the fix to both imagesLocalFetcher and cfImageLocalFetcher in packages/miniflare/src/plugins/images/fetcher.ts, and add a regression test using an EXIF-oriented fixture image. Ensure an explicit user rotate still composes correctly on top of auto-orientation.

Suggested Labels: none (using existing repo labels only; omitting to avoid guessing)

Suggested Comment

Thanks for the detailed report and root-cause analysis — this is really helpful. You're right that the local Images fetchers construct sharp without EXIF auto-orientation, which causes the local/production fidelity gap you're seeing. Passing { autoOrient: true } when constructing sharp in both fetchers looks like the right approach to match production. We'll take a look at getting this fixed (and adding a regression test with an EXIF-oriented fixture). If you'd like to open a PR, we'd be happy to review it.

Structured summary (JSON)

{
  "issueNumber": 15029,
  "title": "Local Images binding ignores EXIF orientation - photos render sideways in local dev",
  "githubUrl": "https://github.com/cloudflare/workers-sdk/issues/15029",
  "recommendation": "KEEP OPEN",
  "difficulty": "easy",
  "reasoning": "Clear, reproducible fidelity bug in Miniflare's local Images binding with a well-identified root cause in packages/miniflare/src/plugins/images/fetcher.ts and a small proposed fix (constructing sharp with autoOrient: true).",
  "suggestedAction": "Apply autoOrient: true to both imagesLocalFetcher and cfImageLocalFetcher, verify it composes with explicit rotate, and add a regression test using an EXIF-oriented fixture image.",
  "hasSuggestedComment": true,
  "suggestedLabels": []
}