[Due for payment 2026-07-22] [$250] iOS - Profile - Cannot upload SVG file as avatar

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: 9.4.34-5
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #95278
Email or phone of affected tester (no customers): n/a
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: iPhone 13 iOS 26.5
App Component: User Settings

Action Performed:

1. Open the app
2. Navigate to Account > Profile
3. Tap on Avatar
4. Select Upload photo
5. Select 'Choose file'
6. Select the SVG file

Expected Result:

The user can successfully upload an SVG image as their avatar.

Actual Result:

An error appears when uploading an SVG file as an avatar.

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome Safari

Screenshots/Videos

Bug7208548_1784067649047.ScreenRecording_07-14-2026_15-42-12_1.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7208548

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022077179039261850433
• Upwork Job ID: 2077179039261850433
• Last Price Increase: 2026-07-14

Issue Owner

Current Issue Owner: @mallenexpensify

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/2fd8b2701a4566dcfe2bc46fbac6abf49ed6205a4b840e420a23962e8e19a125

https://platform.applause.com/services/links/v1/external/24e7ef7faed2a7db2845640e17321e8d4ce6bca15a749f15cf62b50a0df5dbe6

[MelvinBot]

Proposal

What is the root cause of that problem?

SVG is an allowed avatar extension (CONST/index.ts:399), so this is not an "extension not allowed" rejection. The upload fails the resolution check because on native the SVG arrives with no width/height.

On native, the picker reads dimensions straight off the react-native-image-picker asset, and that library does not decode SVG dimensions. The code path that would backfill dimensions via ImageSize.getSize is gated on Str.isImage(), and svg is not in that helper's image list — so an SVG skips both backfill branches and reaches validation with width/height undefined (AttachmentPicker/index.native.tsx:432-461).

Validation then calls getImageResolution.native.ts:12, which returns {width: 0, height: 0} for the missing dimensions. isValidResolution requires >= 80px, so it fails and validateAvatarImage returns the resolutionConstraints error (AvatarUtils.ts:47-53, AvatarUtils.ts:98-110) — "Please upload an image larger than 80x80 pixels…".

Why iOS/Android App only (not web): the web variant creates an Image object and reads naturalWidth/naturalHeight (getImageResolution.ts:19-24), which resolves for SVGs that carry intrinsic dimensions. Only the native path lacks dimensions.

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

SVGs are vector and have no meaningful pixel resolution, so the fix is to skip (or special-case) the min/max resolution check for SVG avatars rather than trying to force pixel dimensions on them:

• In isValidResolution/validateAvatarImage (AvatarUtils.ts), detect an .svg file (by extension/mime) and bypass the AVATAR_MIN_*/AVATAR_MAX_* pixel constraints — an SVG that passes extension + size checks should be accepted.
• Verify the SVG then renders correctly through the avatar crop/preview flow on native; if the crop step also assumes raster dimensions, it may need an SVG-aware branch too.

Data flow & evidence

1. User picks SVG (Account > Profile > Avatar > Upload photo).
2. AttachmentPicker/index.native.tsx builds the file with width/height = undefined (L423-430).
3. Str.isImage('x.svg') is false (its list is jpeg/jpg/gif/png/bmp/webp) → both ImageSize.getSize backfill branches are skipped (L432-461); file returned with no dimensions.
4. validateAvatarImage → extension OK (svg allowed), size OK, corruption check early-resolves (also gated on Str.isImage) → isValidResolution.
5. getImageResolution.native.ts returns {0, 0} → 0 >= 80 is false → resolutionConstraints error shown.

The root inconsistency: svg is whitelisted for avatars but is not treated as an image by the native dimension helpers, so it never gets width/height. Adding svg to Str.isImage alone would not reliably help, since react-native-image-size may still not return dimensions for SVG — skipping the resolution check for SVG is the robust fix.

Confidence: High — deterministic client-side path, fully traced in code; line numbers verified against main (f9f353f).

What alternative solutions did you explore? (Optional)

• Add svg to Str.isImage so it takes the ImageSize.getSize path — rejected as unreliable (SVG may still return no/zero dimensions, reproducing the same failure and possibly a false "corrupted" alert).
• Block SVG for avatars entirely by removing it from AVATAR_ALLOWED_EXTENSIONS — contradicts the Expected Result and existing intent to support SVG avatars.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/96148) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[MobileMage]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-14 23:57:22 UTC.

Proposal

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

On iOS, picking an SVG file as a profile picture (Account > Profile > Avatar > Upload photo > Choose file) is rejected with "Please upload an image larger than 80x80 pixels and smaller than 4096x4096 pixels", even though svg is in CONST.AVATAR_ALLOWED_EXTENSIONS and the same upload works on web. This is not a regression from PR #95278 (it only touched rendering components and the bug reproduces in production) — that PR's QA steps just require setting an SVG profile picture, which exposed this pre-existing native gap.

What is the root cause of that problem?

The error in the QA video is exactly avatarWithImagePicker.resolutionConstraints, which means the failing gate is the resolution check, not the extension or MIME check. On native, "Choose file" runs showDocumentPicker in AttachmentPicker/index.native.tsx, and the picked file comes back as {name, uri, size, type} with no dimensions. In pickAttachment, the branches that hydrate width/height via ImageSize.getSize are gated on Str.isImage(fileDataName):

App/src/components/AttachmentPicker/index.native.tsx

Lines 432 to 435 in 09ce5e0

	if (!shouldValidateImage && fileDataName && Str.isImage(fileDataName)) {
	return getDataForUpload(fileDataObject)
	.then((file) =>
	ImageSize.getSize(file.uri ?? '').then(({width, height}) => ({

Str.isImage in expensify-common only allows ['jpeg', 'jpg', 'gif', 'png', 'bmp', 'webp'], so among all avatar-allowed extensions, SVG is the only one that reaches the avatar flow with width/height undefined. showAvatarCropModal (in src/pages/settings/Profile/Avatar/AvatarPreview.tsx for this screen) then calls validateAvatarImage in src/libs/AvatarUtils.ts: isValidExtension passes (svg is allowed), isValidSize passes, validateImageForCorruption early-returns (also Str.isImage-gated), and finally isValidResolution calls the native getImageResolution, which just echoes the picker metadata:

App/src/libs/fileDownload/getImageResolution.native.ts

Line 12 in 09ce5e0

const getImageResolution: GetImageResolution = (file: Asset) => Promise.resolve({width: file.width ?? 0, height: file.height ?? 0});

That resolves {width: 0, height: 0}, so height >= CONST.AVATAR_MIN_HEIGHT_PX (80) fails and the resolution error is shown. Web works because its getImageResolution loads the file into an Image element, where the browser rasterizes the SVG and reports intrinsic dimensions, and the crop screen then converts the SVG to a PNG blob before upload (the isSvg special case in AvatarCropView.cropAndSaveImage) — so even on web the server never receives an SVG, only its rasterization. Native has no equivalent rasterization step anywhere in the pipeline, and the resolution check is only the first of three stages that choke on a vector: if validation is bypassed, AvatarCropView's init calls ImageSize.getSize(imageUri), which on iOS is just a JS wrapper around Image.getSize (react-native-image-size ships no iOS native module) that rejects for SVG, leaving the crop screen on an infinite spinner, and cropOrRotateImage/index.native.ts uses expo-image-manipulator which cannot decode SVG either. Nothing in the failing path is actually iOS-specific — Android's document picker also returns SVGs without dimensions and hits the same 0x0 — the issue was simply caught during iOS PR QA, so the fix should cover both platforms.

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

Give native the same shape as web: rasterize the SVG to a PNG right after picking, before validation, so the entire existing pipeline (resolution check, crop screen, expo-image-manipulator, upload) operates on a plain raster file with real dimensions. We already ship @shopify/react-native-skia, which can do this headlessly with no component mounting:

const svg = Skia.SVG.MakeFromString(svgXml); // svgXml read from image.uri via RNFetchBlob
const surface = Skia.Surface.Make(width, height); // svg.width()/svg.height(), clamped to CONST.AVATAR_MAX_WIDTH_PX
surface.getCanvas().drawSvg(svg, width, height);
const base64 = surface.makeImageSnapshot().encodeToBase64(ImageFormat.PNG, 100);

The fix adds a platform-split helper (e.g. prepareAvatarImage: web version is an identity pass-through since the browser already rasterizes at crop time; native version detects the svg extension via the existing splitExtensionFromFileName, renders it with Skia, writes the PNG to the cache directory with RNFetchBlob.fs.writeFile(path, base64, 'base64'), and returns a FileObject with type: 'image/png', the .png name, and real width/height/size). It gets called at the top of showAvatarCropModal in the three avatar entry points that share the validateAvatarImage(image).then(... openCropper(image)) pattern — AvatarPreview.tsx, AvatarWithImagePicker.tsx, and EditAgentAvatarPage.tsx — so validateAvatarImage and openCropper receive the prepared file. This is safe because it changes nothing for non-SVG files or for other AttachmentPicker consumers (receipts, chat attachments keep their SVGs untouched), it makes native converge on exactly what web already uploads, and it keeps isValidResolution honest: a genuinely tiny 24x24 SVG icon is rejected on native the same way web rejects it today. The result matches the PNG conversion the crop view already documents for web:

App/src/components/AvatarCropModal/AvatarCropView.tsx

Lines 302 to 306 in 09ce5e0

	// Svg images are converted to a png blob to preserve transparency, so we need to update the
	// image name and type accordingly.
	const isSvg = imageType.includes('image/svg');
	const name = isSvg ? 'fileName.png' : imageName;
	const type = isSvg ? 'image/png' : imageType;

What alternative solutions did you explore? (Optional)

Making getImageResolution.native.ts fall back to ImageSize.getSize(file.uri) when the picker metadata is missing is good hardening for raster files, but it cannot fix SVG (iOS Image.getSize rejects, Android's BitmapFactory returns -1x-1), and simply exempting SVG from the resolution check just moves the failure into the crop screen, where ImageSize.getSize strands iOS on an endless spinner and expo-image-manipulator cannot crop a vector. We also considered dropping svg from the allowed extensions on native to at least show the correct error, but that contradicts the expected result and diverges from web behavior.

[abbasifaizan70]

Proposal

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

On iOS, when a user goes to Account > Profile > Avatar > Upload photo > Choose file and selects an SVG image, an error appears instead of the SVG being accepted as the new avatar.

What is the root cause of that problem?

SVG is explicitly listed as an allowed avatar extension:

App/src/CONST/index.ts

Line 386 in 9813012

AVATAR_ALLOWED_EXTENSIONS: ['jpg', 'jpeg', 'png', 'gif', 'bmp', 'svg'],

However, after the extension and size checks pass, validateAvatarImage unconditionally runs the file through validateImageForCorruption, which relies on the native react-native-image-size module to read the image's pixel dimensions:

App/src/libs/AvatarUtils.ts

Lines 71 to 96 in 9813012

	async function validateAvatarImage(image: FileObject): Promise<ValidationResult> {
	if (!isValidExtension(image)) {
	return {
	isValid: false,
	errorKey: 'avatarWithImagePicker.notAllowedExtension',
	errorParams: {allowedExtensions: CONST.AVATAR_ALLOWED_EXTENSIONS},
	};
	}
	if (!isValidSize(image)) {
	return {
	isValid: false,
	errorKey: 'avatarWithImagePicker.sizeExceeded',
	errorParams: {maxUploadSizeInMB: CONST.AVATAR_MAX_ATTACHMENT_SIZE / (1024 * 1024)},
	};
	}
	try {
	await validateImageForCorruption(image);
	} catch {
	return {
	isValid: false,
	errorKey: 'attachmentPicker.errorWhileSelectingCorruptedAttachment',
	errorParams: {},
	};
	}

ImageSize.getSize decodes raster image headers (JPG/PNG/GIF/BMP) to obtain width/height, but SVG is an XML-based vector format that this native decoder does not support. On iOS this call rejects/throws for SVG files, so validateImageForCorruption always rejects:

App/src/libs/fileDownload/FileUtils.ts

Lines 384 to 400 in 9813012

	function validateImageForCorruption(file: FileObject): Promise<{width: number; height: number} | void> {
	if (!Str.isImage(file.name ?? '') || !file.uri) {
	return Promise.resolve();
	}
	return new Promise((resolve, reject) => {
	ImageSize.getSize(file.uri ?? '')
	.then((size) => {
	if (size.height <= 0 || size.width <= 0) {
	return reject(new Error('Error reading file: The file is corrupted'));
	}
	resolve();
	})
	.catch(() => {
	return reject(new Error('Error reading file: The file is corrupted'));
	});
	});
	}

Because the promise rejects, validateAvatarImage's catch block fires and reports the SVG as a corrupted attachment, even though the file is perfectly valid — SVG was simply never a format this raster-dimension check can evaluate.

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

Skip the raster-only corruption/resolution checks for SVG files in validateAvatarImage, since those checks are meaningless for a vector format and the extension/size checks already guard against unsupported or oversized files:

App/src/libs/AvatarUtils.ts

Lines 71 to 113 in 9813012

	async function validateAvatarImage(image: FileObject): Promise<ValidationResult> {
	if (!isValidExtension(image)) {
	return {
	isValid: false,
	errorKey: 'avatarWithImagePicker.notAllowedExtension',
	errorParams: {allowedExtensions: CONST.AVATAR_ALLOWED_EXTENSIONS},
	};
	}
	if (!isValidSize(image)) {
	return {
	isValid: false,
	errorKey: 'avatarWithImagePicker.sizeExceeded',
	errorParams: {maxUploadSizeInMB: CONST.AVATAR_MAX_ATTACHMENT_SIZE / (1024 * 1024)},
	};
	}
	try {
	await validateImageForCorruption(image);
	} catch {
	return {
	isValid: false,
	errorKey: 'attachmentPicker.errorWhileSelectingCorruptedAttachment',
	errorParams: {},
	};
	}
	const validResolution = await isValidResolution(image);
	if (!validResolution) {
	return {
	isValid: false,
	errorKey: 'avatarWithImagePicker.resolutionConstraints',
	errorParams: {
	minHeightInPx: CONST.AVATAR_MIN_HEIGHT_PX,
	minWidthInPx: CONST.AVATAR_MIN_WIDTH_PX,
	maxHeightInPx: CONST.AVATAR_MAX_HEIGHT_PX,
	maxWidthInPx: CONST.AVATAR_MAX_WIDTH_PX,
	},
	};
	}
	return {isValid: true};
	}

async function validateAvatarImage(image: FileObject): Promise<ValidationResult> {
    if (!isValidExtension(image)) {
        return {
            isValid: false,
            errorKey: 'avatarWithImagePicker.notAllowedExtension',
            errorParams: {allowedExtensions: CONST.AVATAR_ALLOWED_EXTENSIONS},
        };
    }

    if (!isValidSize(image)) {
        return {
            isValid: false,
            errorKey: 'avatarWithImagePicker.sizeExceeded',
            errorParams: {maxUploadSizeInMB: CONST.AVATAR_MAX_ATTACHMENT_SIZE / (1024 * 1024)},
        };
    }

    const {fileExtension} = splitExtensionFromFileName(image?.name ?? '');
    const isSVG = fileExtension.toLowerCase() === 'svg';

    // SVG is a vector format; ImageSize/getImageResolution only support raster formats, so skip those checks for SVGs.
    if (isSVG) {
        return {isValid: true};
    }

    try {
        await validateImageForCorruption(image);
    } catch {
        return {
            isValid: false,
            errorKey: 'attachmentPicker.errorWhileSelectingCorruptedAttachment',
            errorParams: {},
        };
    }
    ...

With this change, SVGs still go through extension and size validation (so unsupported/oversized files are still rejected), but they no longer get incorrectly flagged as "corrupted" by a native decoder that can't parse vector images, fixing the upload error on iOS.

[ahmdshrif]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-14 23:56:48 UTC.

Proposal

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

On the iOS app, picking an SVG via Profile → Avatar → Upload photo → Choose file shows a validation error instead of uploading, even though svg is an explicitly allowed avatar extension.

What is the root cause of that problem?

The native pipeline can only measure image dimensions with the platform bitmap decoders, gated by an image-extension whitelist that excludes svg — so an SVG (a vector file the bitmap stack can't measure) reaches the avatar resolution gate with no dimensions and is rejected as "too small". The chain:

1. "Choose file" uses the document picker, which returns only {name, uri, size, type} — no width/height: index.native.tsx#L326-L339
2. The picker stamps dimensions afterwards via ImageSize.getSize, but only when Str.isImage(name) matches: index.native.tsx#L432-L442. Str.isImage's whitelist is ['jpeg', 'jpg', 'gif', 'png', 'bmp', 'webp'] — no svg: str.ts#L1063-L1071. An SVG falls through to the plain path with width/height still undefined: index.native.tsx#L463
3. In validateAvatarImage, the extension check passes (svg is allowed: CONST/index.ts#L399), size passes, and the corruption check self-skips on the same Str.isImage gate: FileUtils.ts#L384-L387
4. isValidResolution then calls the native getImageResolution, which decodes nothing — it just echoes file.width ?? 0: getImageResolution.native.ts#L12. {0, 0} fails the 80px minimum (AvatarUtils.ts#L47-L54), so validateAvatarImage returns the resolutionConstraints error (AvatarUtils.ts#L98-L110) — the error the tester sees (AvatarWithImagePicker.tsx#L291-L298).

This explains every detail: a PNG picked via "Choose file" works (step 2 stamps it — png is in the whitelist); only SVG fails. Web works because its getImageResolution uses the browser Image, which decodes SVG and reports an intrinsic size: getImageResolution.ts#L13-L33. The Android app shares this exact native path, so it should reproduce there too (only iOS was tested). This is not a regression from PR #95278 (icon rendering only); it repros in production.

Affected paths — validateAvatarImage is the shared gate for every avatar-upload surface: AvatarWithImagePicker (profile, workspace overview, workspace confirmation/duplicate, group chat, report details), AvatarPreview.tsx#L93-L102, and EditAgentAvatarPage — all fail identically for SVG on native.

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

Exempt SVG from the raster-resolution gate at the single convergence point, isValidResolution in AvatarUtils.ts#L47-L54 — a vector file has no pixel resolution, so the 80–4096px constraints don't apply to it (web only "passes" this check via the browser's arbitrary intrinsic size):

async function isValidResolution(image: FileObject): Promise<boolean> {
    // SVG is a vector format: it has no raster resolution to validate,
    // and the native bitmap decoders cannot measure it.
    if (splitExtensionFromFileName(image?.name ?? '').fileExtension.toLowerCase() === 'svg') {
        return true;
    }
    // ... existing check unchanged

This clears the reported error on iOS and Android for all surfaces listed above. Regression safety: the early return only widens acceptance for .svg (already invited by AVATAR_ALLOWED_EXTENSIONS); raster files and web behavior are untouched, and no other consumer reads isValidResolution.

Required companion (same PR, small): the next screen has the same structural dependency — AvatarCropView measures the image with ImageSize.getSize and has no rejection handler: AvatarCropView.tsx#L110-L134. On iOS that library is just RN Image.getSize (the fork ships no iOS native module), which rejects for SVG → isImageInitialized never flips → endless spinner (#L363). Add an SVG branch there that seeds originalImageWidth/Height from the SVG's width/height/viewBox attributes (a cheap text read of the local file) with a square fallback. The rest of the flow is already SVG-aware: the save handler converts SVG→PNG name/type (AvatarCropView.tsx#L302-L306), and on iOS cropOrRotateImage resolves with the original file if native manipulation can't process it (index.native.ts#L46-L58).

Why the obvious one-line fix does not work: patching getImageResolution.native.ts to fall back to ImageSize.getSize(file.uri) when width/height are missing still fails for this bug — on iOS that call is RN Image.getSize, which routes through the UIImage/ImageIO bitmap decoders that cannot decode SVG, so it rejects and the catch returns false (AvatarUtils.ts#L51-L53) — the same error re-appears. Likewise, adding svg to Str.isImage makes it worse: it routes the SVG into the picker's ImageSize.getSize stamping and into validateImageForCorruption's ImageSize.getSize (FileUtils.ts#L389) — both bitmap decodes — so the valid SVG would be alerted as a corrupted attachment instead.

What alternative solutions did you explore? (Optional)

1. ImageSize.getSize fallback in getImageResolution.native.ts — refuted above (bitmap decoder can't measure SVG); worth adding separately as hardening for other dimension-less picks, but it does not fix this bug.
2. Parse the SVG's intrinsic width/height/viewBox and enforce the pixel constraints on those values — treats a scalable image as raster: a perfectly good icon with viewBox="0 0 24 24" would be rejected even though it renders crisply at any avatar size.
3. Skip the crop screen for SVG on native and pass the file straight to onImageSelected — simplest end-to-end path, but diverges from web UX (no crop/zoom) and uploads raw SVG where web uploads rasterized PNG; I'd defer to the team if they prefer this smaller scope.

[aswin-s]

Proposal

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

On iOS, when a user navigates to Account > Profile, taps their avatar, chooses "Upload photo" > "Choose file" and selects an SVG file, an error appears instead of the SVG being accepted as their avatar. Since svg is included in the allowed avatar extensions, the expected result is that the SVG uploads successfully.

What is the root cause of that problem?

validateAvatarImage in src/libs/AvatarUtils.ts:71 calls isValidResolution (line 47), which awaits getImageResolution(image). On native, src/libs/fileDownload/getImageResolution.native.ts:12 simply reads file.width / file.height from the react-native-image-picker Asset. For SVG files, react-native-image-picker does not decode/rasterize the vector, so it returns width: 0, height: 0 (or undefined, which the code coalesces to 0). isValidResolution then checks height >= CONST.AVATAR_MIN_HEIGHT_PX (AvatarUtils.ts:50), which fails for 0×0, causing validateAvatarImage to return the avatarWithImagePicker.resolutionConstraints error — even though SVG is explicitly listed in CONST.AVATAR_ALLOWED_EXTENSIONS (src/CONST/index.ts:399).

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

1. In src/libs/AvatarUtils.ts (validateAvatarImage, ~line 98), skip the resolution check when the file extension is svg — SVGs are resolution-independent vectors, so pixel min/max bounds are not meaningful.
2. Alternatively, inside isValidResolution (AvatarUtils.ts:47), short-circuit and return true when splitExtensionFromFileName(image.name).fileExtension.toLowerCase() === 'svg', keeping the caller unchanged.
3. Verify parity on web: src/libs/fileDownload/getImageResolution.ts uses an Image() object which also cannot decode SVG dimensions reliably across browsers — the same guard should protect web to avoid a symmetric regression.
4. Add a small unit test in tests/unit/AvatarUtilsTest.* covering an SVG FileObject with width/height undefined, asserting validateAvatarImage returns {isValid: true}.

What alternative solutions did you explore? (Optional)

Rasterizing the SVG on iOS to measure dimensions was considered, but it adds a native dependency and is unnecessary because SVG is inherently scalable — bypassing the pixel-bounds check is the correct fix.

[samranahm]

Proposal

What is the root cause of that problem?

On iOS, picking an SVG as a profile avatar (Edit profile picture > Upload photo > Choose file) shows the resolution error even though svg is an allowed avatar extension.

App/src/CONST/index.ts

Line 399 in 5344640

AVATAR_ALLOWED_EXTENSIONS: ['jpg', 'jpeg', 'png', 'gif', 'bmp', 'svg'],

The native document picker returns {name, uri, size, type} with no dimensions. AttachmentPicker.pickAttachment is supposed to backfill width/height with ImageSize.getSize, but that path is gated on Str.isImage(name), and svg is not in that list:

App/src/components/AttachmentPicker/index.native.tsx

Lines 432 to 466 in 5344640

	if (!shouldValidateImage && fileDataName && Str.isImage(fileDataName)) {
	return getDataForUpload(fileDataObject)
	.then((file) =>
	ImageSize.getSize(file.uri ?? '').then(({width, height}) => ({
	...file,
	width,
	height,
	})),
	)
	.catch(handleImageProcessingError);
	}
	if (fileDataName && Str.isImage(fileDataName)) {
	return getDataForUpload(fileDataObject)
	.then((file) =>
	ImageSize.getSize(file.uri ?? '').then(({width, height}) => {
	if (width <= 0 || height <= 0) {
	showImageCorruptionAlert();
	return null;
	}
	return {
	...file,
	width,
	height,
	};
	}),
	)
	.catch(handleImageProcessingError);
	}
	return getDataForUpload(fileDataObject).catch((error: Error) => {
	showGeneralAlert(error.message);
	return null;
	});

So the SVG falls through with width/height undefined. Native getImageResolution only echoes those fields and turns missing values into 0 x 0:

App/src/libs/fileDownload/getImageResolution.native.ts

Line 12 in 5344640

const getImageResolution: GetImageResolution = (file: Asset) => Promise.resolve({width: file.width ?? 0, height: file.height ?? 0});

validateAvatarImage then fails the 80px minimum and shows resolutionConstraints:

App/src/libs/AvatarUtils.ts

Lines 47 to 53 in 5344640

	async function isValidResolution(image: FileObject): Promise<boolean> {
	try {
	const {height, width} = await getImageResolution(image);
	return height >= CONST.AVATAR_MIN_HEIGHT_PX && width >= CONST.AVATAR_MIN_WIDTH_PX && height <= CONST.AVATAR_MAX_HEIGHT_PX && width <= CONST.AVATAR_MAX_WIDTH_PX;
	} catch {
	return false;
	}

App/src/libs/AvatarUtils.ts

Lines 98 to 110 in 5344640

	const validResolution = await isValidResolution(image);
	if (!validResolution) {
	return {
	isValid: false,
	errorKey: 'avatarWithImagePicker.resolutionConstraints',
	errorParams: {
	minHeightInPx: CONST.AVATAR_MIN_HEIGHT_PX,
	minWidthInPx: CONST.AVATAR_MIN_WIDTH_PX,
	maxHeightInPx: CONST.AVATAR_MAX_HEIGHT_PX,
	maxWidthInPx: CONST.AVATAR_MAX_WIDTH_PX,
	},
	};
	}

Web works because its resolver loads a browser Image and reads natural size. Separately, even after validation, the crop screen cannot decode SVG (ImageSize.getSize / Animated.Image / expo-image-manipulator), so a hang or bad save would follow if the gate were only forced open:

App/src/components/AvatarCropModal/AvatarCropView.tsx

Lines 111 to 134 in 5344640

	useEffect(() => {
	if (!imageUri) {
	return;
	}
	// We need to have image sizes in shared values to properly calculate position/size/animation
	ImageSize.getSize(imageUri).then(({width, height, rotation: originalRotation}) => {
	// On Android devices ImageSize library returns also rotation parameter.
	if (originalRotation === 90 || originalRotation === 270) {
	originalImageHeight.set(width);
	originalImageWidth.set(height);
	} else {
	originalImageHeight.set(height);
	originalImageWidth.set(width);
	}
	setIsImageInitialized(true);
	// Because the reanimated library has some internal optimizations,
	// sometimes when the modal is hidden styles of the image and slider might not be updated.
	// To trigger the update we need to slightly change the following values:
	translateSlider.set((value) => value + 0.01);
	rotation.set((value) => value + 360);
	});
	}, [imageUri, originalImageHeight, originalImageWidth, rotation, translateSlider]);

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

Fix the dimension stamp where it already happens for raster files. Do not exempt SVG inside AvatarUtils.

1. Add src/libs/fileDownload/isSvgFile.ts to detect SVG by filename, URI, or type containing svg (covers image/svg+xml and iOS UTIs like public.svg-image).

2. In AttachmentPicker/index.native.tsx pickAttachment, before the Str.isImage branches, detect SVG and call getDataForUpload, then stamp width/height to CONST.AVATAR_MIN_WIDTH_PX / AVATAR_MIN_HEIGHT_PX. Vectors are scalable and ImageSize cannot decode them; this mirrors how raster files get size stamped so shared getImageResolution / isValidResolution keep working unchanged.

App/src/components/AttachmentPicker/index.native.tsx

Lines 423 to 466 in 5344640

	const fileDataObject: FileResponse = {
	name: fileDataName ?? '',
	uri: fileDataUri,
	size: ('size' in fileData && fileData.size) || ('fileSize' in fileData && fileData.fileSize) || null,
	type: fileData.type ?? '',
	width: ('width' in fileData && fileData.width) || undefined,
	height: ('height' in fileData && fileData.height) || undefined,
	};
	if (!shouldValidateImage && fileDataName && Str.isImage(fileDataName)) {
	return getDataForUpload(fileDataObject)
	.then((file) =>
	ImageSize.getSize(file.uri ?? '').then(({width, height}) => ({
	...file,
	width,
	height,
	})),
	)
	.catch(handleImageProcessingError);
	}
	if (fileDataName && Str.isImage(fileDataName)) {
	return getDataForUpload(fileDataObject)
	.then((file) =>
	ImageSize.getSize(file.uri ?? '').then(({width, height}) => {
	if (width <= 0 || height <= 0) {
	showImageCorruptionAlert();
	return null;
	}
	return {
	...file,
	width,
	height,
	};
	}),
	)
	.catch(handleImageProcessingError);
	}
	return getDataForUpload(fileDataObject).catch((error: Error) => {
	showGeneralAlert(error.message);
	return null;
	});

if (isSvgFile({name: fileDataName, uri: fileDataUri, type: fileData.type})) {
    return getDataForUpload(fileDataObject)
        .then((file) => ({
            ...file,
            width: CONST.AVATAR_MIN_WIDTH_PX,
            height: CONST.AVATAR_MIN_HEIGHT_PX,
        }))
        .catch(handleImageProcessingError);
}

3. In useAvatarCrop.openCropper, if the file is SVG, build an uploadable file object and call onCropped immediately (do not navigate to the crop screen). Native crop APIs cannot handle vectors; uploading the SVG matches the expected result.

App/src/hooks/useAvatarCrop.ts

Lines 43 to 58 in 5344640

	const openCropper = (image: FileObject) => {
	const token = rand64();
	tokenRef.current = token;
	// Capture the opener's route now: serialization below is async (slow on web) and the active
	// route can change if the user navigates away before it resolves.
	const baseRoute = Navigation.getActiveRoute();
	setAvatarCropDraft({token, image, openerKey: getOpenerKey(baseRoute), maskType, buttonLabelKey}).then(() => {
	// Abort if the opener unmounted or started a newer crop while serializing — navigating now
	// would yank the user back or open the crop screen under a disallowed entry screen.
	if (tokenRef.current !== token) {
	return;
	}
	// Append `/avatar-crop` to the opener's route so the crop screen opens under its context.
	Navigation.navigate(createDynamicRoute(DYNAMIC_ROUTES.AVATAR_CROP.path, baseRoute));
	});
	};

if (isSvgFile({name: image.name, uri: image.uri, type: image.type})) {
    onCropped(buildUploadableAvatarImage(image));
    return;
}

Leave validateAvatarImage / isValidResolution alone so the resolution gate still runs for every avatar surface once dimensions exist on the file.

Test: unit-test isSvgFile. Manually pick an SVG on iOS Edit profile picture, confirm the 80x80 error is gone, crop is skipped, and Save receives the file.

What alternative solutions did you explore? (Optional)

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

Solution Verification Result

IOS.mp4

[KJ21-ENG]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-14 23:52:12 UTC.

Proposal

What is the root cause of that problem?

SVG is explicitly allowed for avatars, but the native “Choose file” path does not attach image dimensions to a document-picker result. pickAttachment() only backfills dimensions when Str.isImage() recognizes the filename; the installed expensify-common image list contains raster formats but not SVG, so an SVG takes the generic branch with width and height still absent.

App/src/CONST/index.ts

Lines 397 to 403 in f9f353f

	AVATAR_MAX_ATTACHMENT_SIZE: 6291456,
	AVATAR_ALLOWED_EXTENSIONS: ['jpg', 'jpeg', 'png', 'gif', 'bmp', 'svg'],
	// Minimum width and height size in px for a selected image
	AVATAR_MIN_WIDTH_PX: 80,
	AVATAR_MIN_HEIGHT_PX: 80,

App/src/components/AttachmentPicker/index.native.tsx

Lines 326 to 339 in f9f353f

	return pickedFiles.map((file) => {
	const localCopy = localCopies.find((copy) => copy.sourceUri === file.uri);
	if (localCopy?.status !== 'success') {
	throw new Error("Couldn't create local file copy");
	}
	return {
	name: file.name,
	uri: localCopy.localUri,
	size: file.size,
	type: file.type,
	};
	});

App/src/components/AttachmentPicker/index.native.tsx

Lines 414 to 466 in f9f353f

	const filesToProcess = attachments.map((fileData) => {
	if (!fileData) {
	return Promise.resolve(null);
	}
	/* eslint-disable @typescript-eslint/prefer-nullish-coalescing */
	const fileDataName = ('fileName' in fileData && fileData.fileName) || ('name' in fileData && fileData.name) || '';
	const fileDataUri = ('uri' in fileData && fileData.uri) || '';
	const fileDataObject: FileResponse = {
	name: fileDataName ?? '',
	uri: fileDataUri,
	size: ('size' in fileData && fileData.size) || ('fileSize' in fileData && fileData.fileSize) || null,
	type: fileData.type ?? '',
	width: ('width' in fileData && fileData.width) || undefined,
	height: ('height' in fileData && fileData.height) || undefined,
	};
	if (!shouldValidateImage && fileDataName && Str.isImage(fileDataName)) {
	return getDataForUpload(fileDataObject)
	.then((file) =>
	ImageSize.getSize(file.uri ?? '').then(({width, height}) => ({
	...file,
	width,
	height,
	})),
	)
	.catch(handleImageProcessingError);
	}
	if (fileDataName && Str.isImage(fileDataName)) {
	return getDataForUpload(fileDataObject)
	.then((file) =>
	ImageSize.getSize(file.uri ?? '').then(({width, height}) => {
	if (width <= 0 || height <= 0) {
	showImageCorruptionAlert();
	return null;
	}
	return {
	...file,
	width,
	height,
	};
	}),
	)
	.catch(handleImageProcessingError);
	}
	return getDataForUpload(fileDataObject).catch((error: Error) => {
	showGeneralAlert(error.message);
	return null;
	});

https://github.com/Expensify/expensify-common/blob/2.0.191/lib/str.ts#L1063-L1071

The native resolution helper does not decode the selected file; it converts missing dimensions to 0 × 0. validateAvatarImage() then applies the 80–4096 pixel bounds and returns resolutionConstraints. This matches the recording: the supplied SVG declares 800 × 800, but iOS shows the 80–4096 error immediately after selection.

App/src/libs/fileDownload/getImageResolution.native.ts

Lines 5 to 12 in f9f353f

	/**
	* Get image resolution
	* Image object is returned as a result of a user selecting image using the react-native-image-picker
	* Image already has width and height properties coming from library so we just need to return them on native
	* Opposite to web where we need to create a new Image object and get dimensions from it
	*
	*/
	const getImageResolution: GetImageResolution = (file: Asset) => Promise.resolve({width: file.width ?? 0, height: file.height ?? 0});

App/src/libs/AvatarUtils.ts

Lines 47 to 53 in f9f353f

	async function isValidResolution(image: FileObject): Promise<boolean> {
	try {
	const {height, width} = await getImageResolution(image);
	return height >= CONST.AVATAR_MIN_HEIGHT_PX && width >= CONST.AVATAR_MIN_WIDTH_PX && height <= CONST.AVATAR_MAX_HEIGHT_PX && width <= CONST.AVATAR_MAX_WIDTH_PX;
	} catch {
	return false;
	}

App/src/libs/AvatarUtils.ts

Lines 71 to 110 in f9f353f

	async function validateAvatarImage(image: FileObject): Promise<ValidationResult> {
	if (!isValidExtension(image)) {
	return {
	isValid: false,
	errorKey: 'avatarWithImagePicker.notAllowedExtension',
	errorParams: {allowedExtensions: CONST.AVATAR_ALLOWED_EXTENSIONS},
	};
	}
	if (!isValidSize(image)) {
	return {
	isValid: false,
	errorKey: 'avatarWithImagePicker.sizeExceeded',
	errorParams: {maxUploadSizeInMB: CONST.AVATAR_MAX_ATTACHMENT_SIZE / (1024 * 1024)},
	};
	}
	try {
	await validateImageForCorruption(image);
	} catch {
	return {
	isValid: false,
	errorKey: 'attachmentPicker.errorWhileSelectingCorruptedAttachment',
	errorParams: {},
	};
	}
	const validResolution = await isValidResolution(image);
	if (!validResolution) {
	return {
	isValid: false,
	errorKey: 'avatarWithImagePicker.resolutionConstraints',
	errorParams: {
	minHeightInPx: CONST.AVATAR_MIN_HEIGHT_PX,
	minWidthInPx: CONST.AVATAR_MIN_WIDTH_PX,
	maxHeightInPx: CONST.AVATAR_MAX_HEIGHT_PX,
	maxWidthInPx: CONST.AVATAR_MAX_WIDTH_PX,
	},
	};
	}

There is also a downstream native SVG gap. The crop screen initializes from ImageSize.getSize(), while its SVG save branch only changes the requested filename and MIME type before calling the raster image manipulator. If manipulation fails on iOS, the shared helper intentionally returns the original URI but keeps the requested PNG metadata, which can produce original SVG bytes labeled as PNG instead of a cropped conversion.

App/src/components/AvatarCropModal/AvatarCropView.tsx

Lines 109 to 134 in f9f353f

	// In order to calculate proper image position/size/animation, we have to know its size.
	// And we have to update image size if image url changes.
	useEffect(() => {
	if (!imageUri) {
	return;
	}
	// We need to have image sizes in shared values to properly calculate position/size/animation
	ImageSize.getSize(imageUri).then(({width, height, rotation: originalRotation}) => {
	// On Android devices ImageSize library returns also rotation parameter.
	if (originalRotation === 90 || originalRotation === 270) {
	originalImageHeight.set(width);
	originalImageWidth.set(height);
	} else {
	originalImageHeight.set(height);
	originalImageWidth.set(width);
	}
	setIsImageInitialized(true);
	// Because the reanimated library has some internal optimizations,
	// sometimes when the modal is hidden styles of the image and slider might not be updated.
	// To trigger the update we need to slightly change the following values:
	translateSlider.set((value) => value + 0.01);
	rotation.set((value) => value + 360);
	});
	}, [imageUri, originalImageHeight, originalImageWidth, rotation, translateSlider]);

App/src/components/AvatarCropModal/AvatarCropView.tsx

Lines 277 to 315 in f9f353f

	// Crops an image that was provided in the imageUri prop, using the current position/scale
	// then calls onSave callback
	const cropAndSaveImage = useCallback(() => {
	if (isLoading.get()) {
	return;
	}
	isLoading.set(true);
	const smallerSize = Math.min(originalImageHeight.get(), originalImageWidth.get());
	const size = smallerSize / scale.get();
	const imageCenterX = originalImageWidth.get() / 2;
	const imageCenterY = originalImageHeight.get() / 2;
	const apothem = size / 2; // apothem for squares is equals to half of it size
	// Since the translate value is only a distance from the image center, we are able to calculate
	// the originX and the originY - start coordinates of cropping view.
	const originX = imageCenterX - apothem - (translateX.get() / imageContainerSize / scale.get()) * smallerSize;
	const originY = imageCenterY - apothem - (translateY.get() / imageContainerSize / scale.get()) * smallerSize;
	const crop = {
	height: size,
	width: size,
	originX,
	originY,
	};
	// Svg images are converted to a png blob to preserve transparency, so we need to update the
	// image name and type accordingly.
	const isSvg = imageType.includes('image/svg');
	const name = isSvg ? 'fileName.png' : imageName;
	const type = isSvg ? 'image/png' : imageType;
	cropOrRotateImage(imageUri, [{rotate: rotation.get() % 360}, {crop}], {compress: 1, name, type})
	.then((newImage) => {
	onSave?.(newImage);
	})
	.catch(() => {
	isLoading.set(false);
	});
	}, [isLoading, originalImageHeight, originalImageWidth, scale, translateX, imageContainerSize, translateY, imageType, imageName, imageUri, rotation, onSave]);

App/src/libs/cropOrRotateImage/index.native.ts

Lines 17 to 84 in f9f353f

	const cropOrRotateImage: CropOrRotateImage = (uri, actions, options) =>
	new Promise((resolve, reject) => {
	const format = getSaveFormat(options.type);
	const context = ImageManipulator.manipulate(uri);
	for (const action of actions) {
	if ('crop' in action) {
	context.crop(action.crop);
	} else if ('rotate' in action) {
	context.rotate(action.rotate);
	}
	}
	context
	.renderAsync()
	.then((imageRef) => imageRef.saveAsync({compress: options.compress, format}))
	// We need to remove the base64 value from the result, as it is causing crashes on Release builds.
	// More info: https://github.com/Expensify/App/issues/37963#issuecomment-1989260033
	.then(({base64, ...result}) => {
	RNFetchBlob.fs
	.stat(result.uri.replace('file://', ''))
	.then(({size}) => {
	resolve({
	...result,
	size,
	type: options.type || 'image/jpeg',
	name: options.name || 'fileName.jpg',
	});
	})
	.catch(reject);
	})
	.catch((error) => {
	if (Platform.OS !== 'ios') {
	reject(error);
	return;
	}
	Log.warn('Error cropping/rotating image, falling back to original', {error: error instanceof Error ? error.message : String(error)});
	const filePath = uri.replace('file://', '');
	ImageSize.getSize(uri)
	.then(({width, height}) => {
	RNFetchBlob.fs
	.stat(filePath)
	.then(({size}) => {
	resolve({
	uri,
	width: width ?? 0,
	height: height ?? 0,
	size,
	type: options.type || 'image/jpeg',
	name: options.name || 'fileName.jpg',
	});
	})
	.catch(reject);
	})
	.catch(() => {
	RNFetchBlob.fs
	.stat(filePath)
	.then(({size}) => {
	resolve({
	uri,
	width: 0,
	height: 0,
	size,
	type: options.type || 'image/jpeg',
	name: options.name || 'fileName.jpg',
	});
	})
	.catch(reject);
	});

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

Add an avatar-scoped native SVG path while leaving raster attachment and receipt processing unchanged:

• In AvatarUtils, identify SVG after the existing extension and file-size checks and do not apply raster pixel-resolution limits to it. SVG is scalable, so its intrinsic coordinate system should not be treated as a bitmap resolution. Keep the existing corruption and resolution path unchanged for JPG, PNG, GIF, and BMP.
• In AvatarCropView, initialize native SVGs from validated width/height or viewBox data so the crop screen has a reliable aspect ratio and can report malformed/unreadable SVGs instead of waiting indefinitely. Render the SVG through the native SVG renderer while preserving the existing pan, zoom, and rotation transforms.
• For SVG only, capture the transformed image viewport—not the circular mask overlay—with react-native-view-shot and return the captured file’s real PNG URI, MIME type, dimensions, and size. Continue using cropOrRotateImage() for raster inputs, preserving its large-photo iOS fallback and the receipt/scan callers.

The shared validator is used by the profile, agent, and other avatar selectors, and the shared crop view is their convergence point, so this covers every native avatar surface without changing the generic attachment pipeline.

App/src/pages/settings/Profile/Avatar/AvatarPreview.tsx

Lines 90 to 106 in f9f353f

	/**
	* Validates an image and opens avatar crop modal if valid
	*/
	const showAvatarCropModal = (image: FileObject) => {
	validateAvatarImage(image)
	.then((validationResult) => {
	if (!validationResult.isValid) {
	setError(validationResult.errorKey ?? null, validationResult.errorParams ?? {});
	return;
	}
	setError(null, {});
	openCropper(image);
	})
	.catch(() => {
	setError('attachmentPicker.errorWhileSelectingCorruptedAttachment', {});
	});

App/src/components/AvatarWithImagePicker.tsx

Lines 140 to 160 in f9f353f

	}, [source, avatarID]);
	/**
	* Validates an image and opens avatar crop modal if valid
	*/
	const showAvatarCropModal = (image: FileObject) => {
	validateAvatarImage(image)
	.then((validationResult) => {
	if (!validationResult.isValid) {
	setError(validationResult.errorKey ?? null, validationResult.errorParams ?? {});
	return;
	}
	setError(null, {});
	setIsMenuVisible(false);
	openCropper(image);
	})
	.catch(() => {
	setError('attachmentPicker.errorWhileSelectingCorruptedAttachment', {});
	});
	};

App/src/pages/settings/Agents/Fields/EditAgentAvatarPage.tsx

Lines 96 to 116 in f9f353f

	file,
	type: '',
	});
	};
	const {openCropper} = useAvatarCrop({buttonLabelKey: 'avatarPage.upload', onCropped: onImageSelected});
	const showAvatarCropModal = (image: FileObject) => {
	validateAvatarImage(image)
	.then((result) => {
	if (!result.isValid) {
	setErrorData({validationError: result.errorKey ?? null, phraseParam: result.errorParams ?? {}});
	return;
	}
	setErrorData({validationError: null, phraseParam: {}});
	openCropper(image);
	})
	.catch(() => {
	setErrorData({validationError: 'attachmentPicker.errorWhileSelectingCorruptedAttachment', phraseParam: {}});
	});
	};

App/src/components/AvatarCropModal/ImageCropView.tsx

Lines 51 to 91 in f9f353f

	function ImageCropView({imageUri = '', containerSize = 0, panGesture = Gesture.Pan(), maskImage, ...props}: ImageCropViewProps) {
	const icons = useMemoizedLazyExpensifyIcons(['ImageCropCircleMask']);
	const styles = useThemeStyles();
	const StyleUtils = useStyleUtils();
	const containerStyle = StyleUtils.getWidthAndHeightStyle(containerSize, containerSize);
	const originalImageHeight = props.originalImageHeight;
	const originalImageWidth = props.originalImageWidth;
	const rotation = props.rotation;
	const translateX = props.translateX;
	const translateY = props.translateY;
	const scale = props.scale;
	// A reanimated memoized style, which updates when the image's size or scale changes.
	const imageStyle = useAnimatedStyle(() => {
	'worklet';
	const height = originalImageHeight.get();
	const width = originalImageWidth.get();
	const aspectRatio = height > width ? height / width : width / height;
	const rotate = interpolate(rotation.get(), [0, 360], [0, 360]);
	return {
	transform: [{translateX: translateX.get()}, {translateY: translateY.get()}, {scale: scale.get() * aspectRatio}, {rotate: `${rotate}deg`}],
	};
	}, [originalImageHeight, originalImageWidth, rotation, translateX, translateY, scale]);
	// We're preventing text selection with ControlSelection.blockElement to prevent safari
	// default behaviour of cursor - I-beam cursor on drag. See https://github.com/Expensify/App/issues/13688
	return (
	<GestureDetector gesture={panGesture}>
	<Animated.View
	ref={(el: View | null) => ControlSelection.blockElement(el as HTMLElement | null)}
	style={[containerStyle, styles.imageCropContainer]}
	>
	<Animated.Image
	style={[imageStyle, styles.h100, styles.w100]}
	source={{uri: imageUri}}
	resizeMode="contain"
	/>
	<View style={[containerStyle, styles.l0, styles.b0, styles.pAbsolute]}>
	<Icon

Test coverage: add validator tests proving SVG bypasses raster bounds while raster files retain all current checks; add native crop tests for explicit-size and viewBox-only SVGs, malformed SVG handling, and genuine PNG capture metadata/bytes; verify a normal PNG still uses cropOrRotateImage(). Manually select, crop/rotate, save, and reload the supplied SVG avatar on iOS, then repeat with JPEG on iOS and SVG/JPEG on web.

What alternative solutions did you explore? (Optional)

Skipping the crop screen and uploading the raw SVG would clear the immediate error, but it removes the crop/zoom experience and diverges from the existing PNG-output intent. Parsing SVG dimensions and enforcing the 80–4096 bitmap limits would also be misleading because a small viewBox remains resolution-independent. Finally, changing cropOrRotateImage() globally would unnecessarily affect receipt rotation and scan cropping; the vector conversion belongs in the avatar crop flow.