Somebody chooses a new profile picture and the preview changes. That feels like the job is finished. But the preview may only show a file from their device. The public profile may still point to the old image.
I want to think through the whole replacement, because pictures matter to people. They want to know which one is live, whether it fits and what happened to the one they removed.
This example is a possible profile-editing flow. It is not a claim that I have already tested every step in one of my products.
I separate choosing, uploading and saving
Choosing a file gives the browser something to preview. Uploading puts the file in storage. Saving the profile tells the application which stored file to display.
Those can fail separately. If I call all of them “done”, I leave the person guessing when only the first step worked.
I would use clear states such as selected, uploading, ready to save, saved and failed. The language on screen can be simpler, but the application still needs to know the difference.
The old picture should remain until the replacement is ready
I do not want to delete the current image first, then discover that the replacement cannot upload. That can leave the person without either picture.
A safer sequence for this example is to upload the new file, confirm it exists, update the profile reference, and only then consider the old file for cleanup.
Storage and the profile database may not share one transaction. I need recovery for each failure point. If the upload succeeds but the profile save fails, the file can become an unused upload. If cleanup fails after the profile saves, the new picture can still work while cleanup is retried.
I check what the app actually needs
For a profile image, I need a deliberate policy for supported formats, dimensions and file size. I should explain the relevant limits before the person selects a file.
A browser file chooser filter is a convenience, not a security guarantee. Server-side checks and permission controls still matter. OWASP's file-upload guidance explains why an upload needs several checks rather than trusting a filename or the claimed content type.
The exact controls depend on the storage system. I want to understand its rules for serving files and make sure one person cannot replace another person's picture.
A good preview explains the crop
A square profile image may crop a wide photograph. Showing the whole file in the editor can give a false impression of what the public card will display.
I would preview the same shape the visitor will see, including the mobile version. If cropping is supported, the person should control it rather than discover later that part of their face disappeared.
I would also distinguish the selected preview from the saved image. A caption such as “Preview — save to apply” can explain why another page has not changed yet.
Remove and replace are different actions
Removing a picture means the profile should use a deliberate fallback. Replacing it means another picture takes its place.
I want the interface to make that difference clear. A failed replacement should not act like removal, and removal should not quietly delete an unrelated cover image.
If one file is referenced by more than one record, cleanup needs to account for those references. A file being old on one profile does not automatically mean nobody still needs it.
I account for stale images
After a successful update, a browser or CDN may still have the previous image cached. I would check how the storage service handles cache headers and whether a new file receives a new address.
Using a fresh file identity for a replacement can make that easier to reason about. I should avoid promising an instant global refresh without checking the actual serving behaviour.
What I would verify
- Choose a valid file and inspect the actual crop.
- Reject an unsupported or oversized file clearly.
- Fail the upload while preserving the existing picture.
- Fail the profile update after uploading.
- Reopen the public profile and verify the saved reference.
- Check ownership and remove the picture intentionally.
I want the picture the person chose to become the picture people see. That needs a complete flow, including the parts after the preview looks right.
Reference: OWASP File Upload Cheat Sheet.