[Due for payment 2026-08-21] [$250] Improve hover-to-zoom preview quality for non-PDF (image) receipts

[MelvinBot]

Problem

We recently shipped a high-res hover-to-zoom preview for PDF receipts (#93627 / PR #93583, now in production). That fix renders the actual PDF at a higher resolution so hover-zoom reveals sharp pixels.

However, the improvement was intentionally scoped to PDFs only. For non-PDF (image) receipts — e.g. JPG/PNG uploads such as hotel folios — hover-to-zoom still magnifies the low-resolution preview thumbnail. When the underlying image quality is already marginal, the zoomed result is often blurry and unreadable.

Customers who review large volumes of expenses have reported that the New Expensify zoom is noticeably lower quality than Classic, where the same receipt remains legible when enlarged. A recent example was a hotel receipt (HOMEWOOD SUITES) where the New Expensify hover-zoom was too blurry to read while Classic's was clear.

Solution

Bring the higher-quality hover-to-zoom experience to non-PDF (image) receipts, so image receipts are as readable when zoomed as PDFs now are (and as they are in Classic).

Possible approaches to investigate:

• Load/serve a higher-resolution version of the image for the hover-zoom layer (mirroring the PDF overlay approach in PR feat: render high-res PDF overlay on receipt hover zoom #93583), rather than magnifying the small preview thumbnail.
• Balance any quality improvement against preview load performance, since larger images have a performance cost.

Related: #93627 (PDF version of this feature).

Reported in Slack.

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022080717462208245362
• Upwork Job ID: 2080717462208245362
• Last Price Increase: 2026-08-07

Issue Owner

Current Issue Owner: @mallenexpensify

[lorretheboy]

Proposal

What is the root cause of that problem?

Hover-zoom is a pure CSS transform: scale(2.5) of whatever is already rendered in the receipt box:

App/src/components/ReceiptHoverZoom/useReceiptHoverZoom.ts

Lines 66 to 69 in ea66d53

	const x = ((event.clientX - left) / width) * 100;
	const y = ((event.clientY - top) / height) * 100;
	inner.style.transformOrigin = `${x}% ${y}%`;
	inner.style.transform = `scale(${scale})`;

For remote image receipts, what's rendered is never the original file — getThumbnailAndImageURIs returns both the server-generated .1024.jpg thumbnail and the full-resolution image URL:

App/src/libs/ReceiptUtils.ts

Lines 73 to 79 in ea66d53

	if (isReceiptImage) {
	return {
	thumbnail: `${path}.1024.jpg`,
	thumbnail320: `${path}.320.jpg`,
	image: path,
	filename,
	};

but in ReportActionItemImage the remote (non-local, has-thumbnail) branch always displays thumbnailSource; the full-res image URL is only used for navigation and for the PDF overlay:

App/src/components/ReportActionItem/ReportActionItemImage.tsx

Lines 190 to 201 in ea66d53

	} else if (effectiveThumbnail && !effectiveIsLocalFile) {
	propsObj = {
	shouldUseThumbnailImage: shouldUseThumbnailImage ?? true,
	source: thumbnailSource,
	fallbackIcon: icons.Receipt,
	fallbackIconSize: isSingleImage ? variables.iconSizeSuperLarge : variables.iconSizeExtraLarge,
	isAuthTokenRequired: true,
	// If the image is full height, use initial position to make sure it will grow properly to fill the container
	shouldUseInitialObjectPosition: isMapDistanceRequest && !shouldUseFullHeight,
	};

The high-res fix from PR #93583 (ReceiptPDFOverlay renders the source at 2.5× and downscales it) is explicitly gated to remote PDFs only:

App/src/components/ReportActionItem/ReportActionItemImage.tsx

Lines 226 to 228 in ea66d53

	const pdfSourceURL = typeof originalImageSource === 'string' && !!originalImageSource ? originalImageSource : undefined;
	const isRemotePDF = !!isPDF && !effectiveIsLocalFile && !isEReceipt && !isMapBasedDistanceRequest(transaction) && !!pdfSourceURL;
	const shouldOverlayHighResPDF = canZoomReceipt && isRemotePDF && hasHoverSupport();

So for a JPG/PNG receipt the chain is: only the 1024px thumbnail is ever loaded → the browser scales it 2.5× (5× on retina) → the zoomed view is upscaled thumbnail pixels, hence blurry, while Classic shows the original file.

What changes do you think we should make in order to solve the problem?

Fix it in ReportActionItemImage (the same convergence point PR #93583 used, so Search/preview thumbnails elsewhere are untouched). In the remote-image branch, when zoom applies — the same condition as the PDF overlay, canZoomReceipt && hasHoverSupport(), and the receipt is a remote image (Str.isImage(filename)) — display the full-resolution originalImageSource instead of the 1024 thumbnail, and pass the existing .1024.jpg thumbnailSource as previewUri so ThumbnailImage/ImageWithLoading shows the thumbnail instantly and swaps to the original when it finishes loading (this placeholder mechanism already exists):

App/src/components/ReceiptImage/index.tsx

Lines 142 to 143 in ea66d53

	/** Low-resolution URI shown as a placeholder while the full image loads */
	previewUri?: string;

Roughly, in the effectiveThumbnail && !effectiveIsLocalFile branch:

const shouldLoadFullResImage = canZoomReceipt && hasHoverSupport() && Str.isImage(filename ?? '') && typeof originalImageSource === 'string';
propsObj = {
    ...,
    source: shouldLoadFullResImage ? originalImageSource : thumbnailSource,
    previewUri: shouldLoadFullResImage ? thumbnailSource : undefined,
    ...
};

Performance stays bounded: canZoomReceipt is only passed by MoneyRequestReceiptView (the single receipt in the expense RHP), and only hover-capable devices download the original — mobile and list views keep using thumbnails.

What alternative solutions did you explore? (Optional)

Mirroring the PDF approach literally with an absolutely-positioned full-res <img> overlay that only mounts on first hover (via the isHovering render prop of ReceiptHoverZoom), so the original is downloaded only when the user actually hovers. Slightly cheaper on bandwidth, but adds an overlay layer and a visible sharpen-on-hover pop; loading the original eagerly with the thumbnail as placeholder is simpler and matches how the PDF overlay behaves today.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @bernhardoj (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022080717462208245362

[godzillaxbox19982014-lgtm]

Proposal

Please re-state the problem that we are trying to solve in this issue.

Improve hover-to-zoom preview quality for non-PDF (image) receipts

What is the root cause of that problem?

I traced this to the path that handles expense report, PDF, PDFs:

• src/components/TransactionItemRow/ReceiptPreview/index.tsx:123 (shouldShowImage): const shouldShowImage = source && !(isEReceipt || isDistanceEReceipt || isPerDiemEReceipt);
• src/components/ReceiptImage/index.tsx:261 (if): if (e.nativeEvent.layout.width !== receiptImageWidth && e.timeStamp - lastUpdateWidthTimestampRef.current > MIN_UPDATE_WIDTH_DIFF) {
• src/components/TransactionItemRow/ReceiptPreview/getAnchoredPreviewPosition.ts:43 (min): return {left, top: Math.min(Math.max(anchorPosition.top, RECEIPT_PREVIEW_EDGE_MARGIN), Math.max(RECEIPT_PREVIEW_EDGE_MARGIN, lowestTop))};
• src/components/TransactionItemRow/ReceiptPreview/index.tsx:75 (if): if (height * eReceiptScaleFactor > windowHeight - CONST.RECEIPT_PREVIEW_TOP_BOTTOM_MARGIN) {
• src/components/TransactionItemRow/ReceiptPreview/index.tsx:123 is the first concrete decision that matches expense report, PDF, PDFs, and src/components/ReceiptImage/index.tsx:261 is the next matching consumer/mutation. The failing behavior is introduced at this handoff: the second path does not preserve the condition/state established by the first path for the repro case.

What changes do you think we should make in order to solve the problem?

• Change the issue-matching decision at src/components/TransactionItemRow/ReceiptPreview/index.tsx:123 so the expense report, PDF, PDFs repro state is represented before src/components/ReceiptImage/index.tsx:261 consumes it.
• Keep the patch at this first decision/consumer boundary (align optimistic/success/failure data with the selector consumed by the screen) instead of masking the downstream UI symptom.
• Keep the change inside the Reports, Expenses, IOU, Transactions surface and avoid changing payment actions, personal/deleted policies.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

1. Add or update a regression in tests/ui/components/IOURequestStepConfirmation*.tsx for the exact issue flow: Improve hover-to-zoom preview quality for non-PDF (image) receipts.
2. Cover the counter-case near src/components/TransactionItemRow/ReceiptPreview/index.tsx:123 so valid existing expense report, PDF, PDFs behavior still works.
3. Manually repeat the issue steps after the patch and confirm the visible state/action is no longer stale.

What alternative solutions did you explore? (Optional)

• I would not add a broad new condition outside these referenced paths; the safer fix is to keep expense report, PDF, PDFs consistent at the first read/write boundary shown above.

[wildan-m]

Proposal

Please re-state the problem that we are trying to solve in this issue.

Hover-to-zoom on a non-PDF (image) receipt magnifies the low-resolution server preview thumbnail rather than the actual uploaded image, so the zoomed result is blurry and often unreadable — noticeably worse than Expensify Classic. The equivalent problem was already fixed for PDF receipts, but that fix was deliberately scoped to PDFs only, so image receipts (JPG/PNG uploads such as hotel folios) still zoom into an upscaled thumbnail.

What is the root cause of that problem?

For a remote image receipt, getThumbnailAndImageURIs returns two different URLs: a server-generated 1024px derivative as thumbnail, and the full-resolution original upload as image:

App/src/libs/ReceiptUtils.ts

Lines 73 to 80 in ea66d53

	if (isReceiptImage) {
	return {
	thumbnail: `${path}.1024.jpg`,
	thumbnail320: `${path}.320.jpg`,
	image: path,
	filename,
	};
	}

ReportActionItemImage then always renders the 1024px derivative for remote receipts — the branch that handles them passes thumbnailSource (i.e. the .1024.jpg file) to ReceiptImage, and never the original:

App/src/components/ReportActionItem/ReportActionItemImage.tsx

Lines 190 to 201 in ea66d53

	} else if (effectiveThumbnail && !effectiveIsLocalFile) {
	propsObj = {
	shouldUseThumbnailImage: shouldUseThumbnailImage ?? true,
	source: thumbnailSource,
	fallbackIcon: icons.Receipt,
	fallbackIconSize: isSingleImage ? variables.iconSizeSuperLarge : variables.iconSizeExtraLarge,
	isAuthTokenRequired: true,
	// If the image is full height, use initial position to make sure it will grow properly to fill the container
	shouldUseInitialObjectPosition: isMapDistanceRequest && !shouldUseFullHeight,
	};

Hover zoom does not swap in a better source. ReceiptHoverZoom is purely a CSS transform — it applies scale(2.5) to whatever DOM node is already mounted underneath it:

App/src/components/ReceiptHoverZoom/useReceiptHoverZoom.ts

Lines 66 to 70 in ea66d53

	const x = ((event.clientX - left) / width) * 100;
	const y = ((event.clientY - top) / height) * 100;
	inner.style.transformOrigin = `${x}% ${y}%`;
	inner.style.transform = `scale(${scale})`;
	if (!hovering) {

So the browser is asked to magnify a fixed 1024px raster with no extra source pixels behind it. In the receipt view the image box is only a few hundred CSS pixels wide, which on a 2x-density display already consumes most of those 1024 pixels at rest; multiplying by the 2.5x zoom factor demands far more pixels than the derivative contains, and the browser can only interpolate. That interpolation is the blur.

This is exactly the failure mode that was fixed for PDFs, and the fix is gated so it cannot apply here. ReportActionItemImage mounts the high-resolution ReceiptPDFOverlay only when the receipt is a PDF:

App/src/components/ReportActionItem/ReportActionItemImage.tsx

Lines 226 to 228 in ea66d53

	const pdfSourceURL = typeof originalImageSource === 'string' && !!originalImageSource ? originalImageSource : undefined;
	const isRemotePDF = !!isPDF && !effectiveIsLocalFile && !isEReceipt && !isMapBasedDistanceRequest(transaction) && !!pdfSourceURL;
	const shouldOverlayHighResPDF = canZoomReceipt && isRemotePDF && hasHoverSupport();

Because isRemotePDF requires isPDF, image receipts fall through to the thumbnail-only path and keep magnifying the 1024px derivative. The higher-resolution source they need is already resolved in the same component as originalImageSource — the PDF overlay and the local-file branches consume it, but on the remote-image path it goes unused.

What changes do you think we should make in order to solve the problem?

Mirror the PDF overlay approach for image receipts, so hover zoom magnifies real pixels from the original upload instead of interpolated pixels from the derivative.

Add a sibling of ReceiptPDFOverlay for images — a small web-only component that renders the original receipt image, absolutely positioned to fill the same box as the thumbnail underneath it, with the same cover fit, object position and aspect-ratio handling the thumbnail uses so the two register pixel-for-pixel and there is no visible shift when it appears. It takes the already-resolved original URL and hands it to the shared image component with the auth-token flag set, so the encrypted token is appended exactly as it is for the thumbnail. It also reuses the PDF overlay's oversample-then-downscale trick — laying the image out in a container scaled up by the zoom factor and scaling the container back down — so the browser rasterises it with enough detail for the magnified state instead of stretching a texture rasterised at rest size. As with the PDF overlay, the native platform file returns nothing, since hover zoom is a web-only interaction.

In ReportActionItemImage, generalise the existing overlay decision instead of duplicating it. Keep the current PDF branch as-is, and add a parallel condition for remote image receipts: mount the image overlay when the receipt can be zoomed, hover is supported, the receipt is a remote (non-local) image rather than a PDF, is not an eReceipt, is not a map-based distance request, and a resolved original URL exists. Reuse the same renderReceiptContent wrapper that already layers an overlay over the receipt so the layout and pointer-events handling stay identical, and only the overlay component differs.

Keep the thumbnail mounted underneath, exactly as the PDF fix does. It is what makes this safe: the 1024px derivative still paints immediately so there is no perceived slowdown in the first render, the overlay keeps itself hidden until the original has loaded and measured, and if the original fails to load the overlay renders nothing and the thumbnail remains visible. Reuse the PDF overlay's failure handling — track the URL that failed and compare it against the current URL during render, so the failure state resets automatically when the URL changes (for example after an auth-token refresh) without needing an effect.

To address the load-performance concern raised in the issue, defer the full-resolution fetch until it is actually needed rather than downloading it for every receipt that happens to be on screen. ReceiptHoverZoom already exposes an isHovering flag to its children, and MoneyRequestReceiptView already destructures it for the distance eReceipt overlay:

App/src/components/ReportActionItem/MoneyRequestReceiptView.tsx

Lines 671 to 698 in ea66d53

	<ReceiptHoverZoom
	isEnabled={canHoverZoomReceipt}
	hoverContainerRef={receiptContainerRef}
	>
	{({isHovering}) => (
	<>
	<ReportActionItemImage
	shouldUseThumbnailImage={!fillSpace}
	shouldUseFullHeight={fillSpace}
	canZoomReceipt={canZoomReceipt}
	thumbnail={receiptURIs?.thumbnail}
	fileExtension={receiptURIs?.fileExtension}
	isThumbnail={receiptURIs?.isThumbnail}
	image={receiptURIs?.image}
	isLocalFile={receiptURIs?.isLocalFile}
	filename={receiptURIs?.filename}
	transaction={updatedTransaction ?? transaction}
	enablePreviewModal
	readonly={readonly || !canEditReceipt}
	mergeTransactionID={mergeTransactionID}
	report={report}
	onLoad={() => setIsLoading(false)}
	onLoadFailure={() => setIsLoading(false)}
	/>
	{canShowDistanceEReceipt && isHovering && !!displayedTransaction && <HoveredDistanceEReceipt transaction={displayedTransaction} />}
	</>
	)}
	</ReceiptHoverZoom>

Thread that same flag down so the image overlay mounts on first hover and then stays mounted for the lifetime of the view. That way the original is fetched only for receipts the user actually inspects, it is fetched once rather than on every hover, and the thumbnail covers the brief window before it decodes. This keeps the common case — scrolling past receipts without hovering — at exactly today's network cost, while the zoom quality improves for the receipts that are actually examined.

Scope stays limited to remote image receipts on web. Local files already point at the original upload, PDFs keep their existing overlay, eReceipts and map-based distance requests are excluded because their hover layer is a generated card rather than a photo, and native is unaffected because it has no hover zoom.

The result is that zooming a hotel folio or any other photographed receipt shows the detail that was actually uploaded, matching the sharpness Classic provides and the sharpness PDFs now provide in New Expensify.

Compare branch: https://github.com/Expensify/App/compare/main...wildan-m:App:wildan/96999-image-receipt-hover-zoom?expand=1

What alternative solutions did you explore? (Optional)

Simply switching source from thumbnailSource to originalImageSource in the remote-receipt branch. This is the smallest possible diff and it does fix the blur, but it regresses performance broadly: that branch feeds every remote receipt surface, including report previews and list rows where several receipts render at once, so every one of them would download a multi-megabyte original instead of the small derivative. The derivative exists precisely to avoid that cost, so removing it wholesale trades one user complaint for a worse one.

Requesting a larger server-side derivative — for example a 2048px variant alongside the existing 1024px and 320px ones. This would be a smaller client change, but it depends on the backend actually generating and serving that size, which the App repo cannot guarantee on its own, and it only moves the ceiling rather than removing it: any zoom factor large enough will blur a fixed-size derivative again. The original upload is the only source that is guaranteed to exist and is guaranteed to be at least as detailed as anything derived from it.

Lowering the hover zoom factor so the derivative is never over-magnified. This would make the zoom look sharp, but only by making it zoom less, which removes the value of the feature rather than fixing its quality — and it would degrade the PDF experience that was just improved.

[dilshodmackbook-sketch]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-24 18:17:42 UTC.

Proposal

Please re-state the problem that we are trying to solve in this issue.

Hover-to-zoom on a non-PDF (image) receipt magnifies the server's low-resolution preview thumbnail instead of the uploaded image, so the zoomed result is blurry and often unreadable — noticeably worse than Classic. The same problem was fixed for PDF receipts in PR #93583, but that fix was intentionally scoped to PDFs only, so JPG/PNG receipts (e.g. hotel folios) still zoom into an upscaled thumbnail.

What is the root cause of that problem?

For a remote image receipt, getThumbnailAndImageURIs resolves two separate URLs — the server's .1024.jpg derivative as thumbnail, and the full-resolution upload as image:

App/src/libs/ReceiptUtils.ts

Lines 73 to 80 in ea66d53

	if (isReceiptImage) {
	return {
	thumbnail: `${path}.1024.jpg`,
	thumbnail320: `${path}.320.jpg`,
	image: path,
	filename,
	};
	}

But the remote branch of ReportActionItemImage always renders the .1024.jpg derivative (source: thumbnailSource). The full-resolution originalImageSource is resolved in the very same component, but it's only used to open the attachment modal — never for the preview:

App/src/components/ReportActionItem/ReportActionItemImage.tsx

Lines 190 to 201 in ea66d53

	} else if (effectiveThumbnail && !effectiveIsLocalFile) {
	propsObj = {
	shouldUseThumbnailImage: shouldUseThumbnailImage ?? true,
	source: thumbnailSource,
	fallbackIcon: icons.Receipt,
	fallbackIconSize: isSingleImage ? variables.iconSizeSuperLarge : variables.iconSizeExtraLarge,
	isAuthTokenRequired: true,
	// If the image is full height, use initial position to make sure it will grow properly to fill the container
	shouldUseInitialObjectPosition: isMapDistanceRequest && !shouldUseFullHeight,
	};

Hover zoom adds no pixels of its own — useReceiptHoverZoom is a pure CSS transform: scale(...) applied to whatever node is already mounted underneath it:

App/src/components/ReceiptHoverZoom/useReceiptHoverZoom.ts

Lines 58 to 69 in ea66d53

	const updateZoomOrigin = (event: PointerEvent) => {
	if (!bounds) {
	bounds = target.getBoundingClientRect();
	}
	const {left, top, width, height} = bounds;
	if (!width || !height) {
	return;
	}
	const x = ((event.clientX - left) / width) * 100;
	const y = ((event.clientY - top) / height) * 100;
	inner.style.transformOrigin = `${x}% ${y}%`;
	inner.style.transform = `scale(${scale})`;

So the browser is asked to magnify a fixed 1024px raster by 2.5× (more on a retina display) with no extra source behind it, and it can only interpolate — that interpolation is the blur. The sharp path already exists, but isRemotePDF requires isPDF, so image receipts never reach it and fall through to the thumbnail-only branch:

App/src/components/ReportActionItem/ReportActionItemImage.tsx

Lines 226 to 228 in ea66d53

	const pdfSourceURL = typeof originalImageSource === 'string' && !!originalImageSource ? originalImageSource : undefined;
	const isRemotePDF = !!isPDF && !effectiveIsLocalFile && !isEReceipt && !isMapBasedDistanceRequest(transaction) && !!pdfSourceURL;
	const shouldOverlayHighResPDF = canZoomReceipt && isRemotePDF && hasHoverSupport();

What changes do you think we should make in order to solve the problem?

Upgrade the receipt's own image source to the full-resolution original on hover — no second overlay layer. In the remote branch of ReportActionItemImage, when the receipt is zoom-capable, hover is supported, it's a remote image (not a PDF/eReceipt/map distance request), and the pointer is actually over the receipt, render originalImageSource and pass the .1024.jpg thumbnailSource as previewUri:

const shouldUpgradeToFullRes = canZoomReceipt && hasHoverSupport() && isReceiptHovered && Str.isImage(filename ?? '') && typeof originalImageSource === 'string';

// in the `effectiveThumbnail && !effectiveIsLocalFile` branch
propsObj = {
    shouldUseThumbnailImage: shouldUseThumbnailImage ?? true,
    source: shouldUpgradeToFullRes ? originalImageSource : thumbnailSource,
    previewUri: shouldUpgradeToFullRes ? thumbnailSource : undefined,
    isAuthTokenRequired: true,
    // ...unchanged
};

ReceiptImage already renders previewUri first and swaps to source once it decodes — it forwards previewUri to both its render paths, ThumbnailImage and ImageWithLoading:

App/src/components/ReceiptImage/index.tsx

Lines 142 to 143 in ea66d53

	/** Low-resolution URI shown as a placeholder while the full image loads */
	previewUri?: string;

So the 1024px thumbnail keeps painting instantly and the original replaces it in the same node ReceiptHoverZoom scales — there's no separate layer to register, no shift when it appears, and if the original fails to load the thumbnail simply stays.

ReceiptHoverZoom already exposes isHovering, and MoneyRequestReceiptView already destructures it (it uses it for the distance-eReceipt overlay). Thread that same flag into ReportActionItemImage as a new prop, latched so it stays true after the first hover — the receipt upgrades once and keeps the sharp source for the lifetime of the view:

App/src/components/ReportActionItem/MoneyRequestReceiptView.tsx

Lines 671 to 691 in ea66d53

	<ReceiptHoverZoom
	isEnabled={canHoverZoomReceipt}
	hoverContainerRef={receiptContainerRef}
	>
	{({isHovering}) => (
	<>
	<ReportActionItemImage
	shouldUseThumbnailImage={!fillSpace}
	shouldUseFullHeight={fillSpace}
	canZoomReceipt={canZoomReceipt}
	thumbnail={receiptURIs?.thumbnail}
	fileExtension={receiptURIs?.fileExtension}
	isThumbnail={receiptURIs?.isThumbnail}
	image={receiptURIs?.image}
	isLocalFile={receiptURIs?.isLocalFile}
	filename={receiptURIs?.filename}
	transaction={updatedTransaction ?? transaction}
	enablePreviewModal
	readonly={readonly || !canEditReceipt}
	mergeTransactionID={mergeTransactionID}
	report={report}

Because the upgrade is gated on an actual hover, scrolling a report or opening the RHP without hovering stays at exactly today's network cost — the multi-MB original is fetched only for the single receipt the user actually inspects, and only on hover-capable devices. Local files (already full-res), PDFs (existing overlay), eReceipts, and map-based distance requests are all excluded for the same reasons the PDF path excludes them.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

1. Hovering a remote image receipt in the expense RHP swaps the rendered source from thumbnailSource to originalImageSource (and passes thumbnailSource as previewUri), while a PDF receipt keeps the existing ReceiptPDFOverlay path unchanged.
2. An image receipt that is rendered but never hovered issues no full-resolution request — list rows, report previews, and RHP-open-without-hover keep loading only the .1024.jpg derivative.
3. When the receipt is not zoom-capable or hover is unsupported (native/touch), the source stays thumbnailSource.

What alternative solutions did you explore? (Optional)

• Mount a parallel full-res overlay component mirroring ReceiptPDFOverlay (e.g. a ReceiptHighResImageOverlay absolutely filling the box over the thumbnail). This works, but it adds a second web-only image layer that has to register pixel-for-pixel with the thumbnail underneath to avoid a visible shift as it fades in, and duplicates the overlay's load/failure bookkeeping. Upgrading the existing image's own source reuses the node already being zoomed and the previewUri placeholder/fallback machinery, so there is no registration problem and no new component.
• Eagerly swap source to the original (drop the hover gate). This is the smallest change, but it downloads the full original as soon as the receipt renders even if the user never zooms; gating on a real hover keeps the common case at today's cost while still improving the receipts that are actually examined.
• Request a larger server derivative (e.g. .2048.jpg). getThumbnailAndImageURIs only produces .320.jpg and .1024.jpg; the App can't guarantee the backend serves a bigger size, and any fixed size blurs again at a high enough zoom. The original upload is the only guaranteed-sharp source.

[elbarryamine]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-24 18:24:01 UTC.

Proposal

What is the root cause of that problem?

The hover-to-zoom is a CSS transform that magnifies whatever is already rendered inside the receipt container. useReceiptHoverZoom tracks the pointer and applies:

https://github.com/Expensify/App/blob/main/src/components/ReceiptHoverZoom/useReceiptHoverZoom.ts

inner.style.transformOrigin = `${x}% ${y}%`;
inner.style.transform = `scale(${scale})`;

So zoom sharpness is capped by the resolution the receipt was rendered at — not by the source file.

For a remote image receipt, the rendered element is the server's JPEG thumbnail, because ReportActionItemImage always picks the thumbnail branch for remote receipts:

https://github.com/Expensify/App/blob/main/src/components/ReportActionItem/ReportActionItemImage.tsx#L190-L201

} else if (effectiveThumbnail && !effectiveIsLocalFile) {
    propsObj = {
        shouldUseThumbnailImage: shouldUseThumbnailImage ?? true,
        source: thumbnailSource,   // <- 1024px server thumbnail (`${path}.1024.jpg`, see ReceiptUtils)
        ...

Scaling a 1024px raster ~3x is exactly the reported blur.

PDFs had the same root cause, and the shipped fix (PR #93583) documents it in this very file — for PDFs only:

// A remote PDF is shown as the server's low-resolution JPG thumbnail, which blurs when hover-zoomed.
// Where zooming is available (web only), render the actual PDF on top of the thumbnail so the magnified
// view stays sharp. The thumbnail stays underneath as an instant preview and as a fallback...
const isRemotePDF = !!isPDF && !effectiveIsLocalFile && !isEReceipt && !isMapBasedDistanceRequest(transaction) && !!pdfSourceURL;
const shouldOverlayHighResPDF = canZoomReceipt && isRemotePDF && hasHoverSupport();

Images never got the equivalent branch — the full-resolution original (receiptURIs.image / originalImageSource) is already wired into the component but is unused in the zoomed view.

What changes do you think we should make in order to solve the problem?

Extend the existing high-res overlay pattern from PDFs to remote image receipts, in ReportActionItemImage:

1. Add the analogous condition next to shouldOverlayHighResPDF:

const isRemoteImage = !!filename && Str.isImage(filename) && !effectiveIsLocalFile && !isEReceipt && !isMapBasedDistanceRequest(transaction) && !!originalImageSource;
const shouldOverlayHighResImage = canZoomReceipt && isRemoteImage && hasHoverSupport();

2. In renderReceiptContent, when shouldOverlayHighResImage, absolutely-fill an <Image> with originalImageSource (with isAuthTokenRequired) on top of the thumbnail — mirroring ReceiptPDFOverlay: the thumbnail underneath stays as the instant preview and fallback while the full-res image loads, and the CSS zoom then magnifies real pixels.

This reuses the accepted pattern (same UX, same fallback semantics as the PDF fix), touches one file, and needs no new network endpoints since the full-res URL already exists. Hover-zoom is web-only (hasHoverSupport()), so native is unaffected.

What alternative solutions did you explore? (Optional)

Switching the thumbnail branch to pass source: originalImageSource whenever canZoomReceipt — simpler, but it loads the heavy original even for users who never hover, and loses the instant-thumbnail-then-sharpen behavior the PDF fix deliberately kept. The overlay approach matches the established precedent.

[dilshodmackbook-sketch]

Proposal updated — I reworked the fix. Instead of layering a separate full-res overlay over the thumbnail, I upgrade the receipt's own image source to the original on hover and keep the 1024 thumbnail as the previewUri placeholder, so there's no second layer to register and no eager download for receipts nobody zooms.