Give a file-size rejection its own result in an image-preview flow. You can check the selected file's byte budget before starting decoding, then report a size problem without calling it an image-decoding failure.
MDN documents File.size, inherited from Blob, as a byte count for the stored file. It is not the size of a decoded pixel buffer. This guard uses an example limit of 8 MiB; a file exactly at that limit passes.
function checkFileBudget(file, maxBytes) {
if (!file) return { ok: false, reason: "no-file" };
if (file.size > maxBytes) {
return { ok: false, reason: "file-too-large" };
}
return { ok: true };
}
const budget = 8 * 1024 * 1024; // example policy: 8 MiB
Run the guard before starting preview work. When ok is false, stop and show its reason. Replace the example budget with the limit your endpoint actually requires, and state the unit in the message.
A passing result says only that the file fits this byte budget. The decoder can still fail. Handle that failure separately from an upload response that the server rejects. Enforce the upload requirements on the server as well.
The file input's accept attribute does not close that gap. As MDN explains, it guides the file picker rather than validating the chosen file's type. Selection through an image-oriented picker is not evidence that an upload is valid.
References:
https://developer.mozilla.org/en-US/docs/Web/API/Blob/size
https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Attributes/accept
I work on Morphio (https://morphio.online/). This example describes an image-handling check, without claiming that it is a particular product's implementation.