NOPPAWYour photo is sharp, small and exactly the right dimensions — and the form still says no. If the file ends in .webp, the problem is almost certainly not the photo. WebP arrived in 2010, which makes it a teenager, but plenty of upload forms were built earlier and never revisited. This guide explains the machinery behind the rejection, why renaming the file is a trap, and how to convert properly so the next upload simply works.
The form was built before WebP
Upload validation is usually a list, written once: JPG, PNG, maybe GIF, full stop. Enterprise and government systems — exactly the systems behind application portals, campus registrations and HR software — change slowly, get audited cautiously, and often run image libraries that predate WebP support. The form is not judging your file; it is pattern-matching against a allowlist from another decade. Even some newer systems accept WebP at the door and then fail downstream, when a thumbnail generator or PDF report builder chokes on it. From the applicant's side the lesson is plain: for anything official, the boring formats win.
An extension is not a format
Renaming photo.webp to photo.jpg changes the label, not the contents — the file still holds WebP data under a JPG name. Some forms accept the renamed file because they only check the extension, which feels like a victory and is actually a deferred failure: the receiving system may store it, fail to thumbnail it, print it as a blank box, or hand a confused reviewer a file their viewer cannot open. Validators that sniff the actual bytes reject the renamed file on the spot, which is at least honest. Either way, renaming trades a clear rejection today for an unclear failure later, possibly after the deadline. Convert the file for real; it takes the same thirty seconds.
There is a second, quieter layer to the same problem: content sniffing. Some servers ignore the extension and read the file's opening bytes to decide what it really is, while others trust the extension completely and never look inside. A genuine WebP file can therefore be rejected by the sniffer for being WebP, accepted by the trusting server and then mishandled by every tool downstream that believed the label. You cannot see which design a given portal uses — you only see the rejection, or the blank thumbnail a week later. That uncertainty is the practical argument for sending the format the form was built for, rather than the format that merely gets past its front door.
Converting without quality surprises
A proper conversion decodes the WebP once and re-encodes it as a genuine JPG — the WebP to JPG converter does this entirely in your browser. One decode-and-encode cycle at a sensible quality is visually invisible for photographs; what degrades images is repeated lossy re-saving, the photocopy-of-a-photocopy effect. So convert from the WebP original, keep that original untouched, and never convert a JPG back and forth hunting for a smaller file. If you are comparing several outcomes at once — JPG for the form, PNG for a graphic, a smaller version for email — the Image Converter handles the formats side by side.
The PNG transparency trap
WebP supports transparency; JPG does not. Convert a WebP logo or signature with a transparent background to JPG and the see-through area has to become something — conventionally a solid white fill — which is how crisp logos end up pasted-looking inside white boxes on coloured pages. When the destination cares about transparency, convert to PNG instead (there is a dedicated WebP to PNG route), accepting the larger file as the price of keeping the alpha channel. The reverse trip has the same logic: JPG to PNG is useful when a workflow demands PNG, but it cannot invent transparency that the JPG never had. Format choices are one-way doors more often than they look.
Which format to send instead
- Photographs and scans: JPG. Universal, compact, and what nearly every form secretly expects.
- Logos, signatures, graphics with transparency: PNG. Bigger, but the background survives.
- Screenshots with small text: PNG if the form allows it; JPG blurs fine text at low quality settings.
- When the form lists formats: obey the list literally, even when WebP is technically better — the list is the law of that upload box.
And keep the master file in whatever format it was born in. Converted copies are for sending; originals are for keeping.
If the form still says no
Converted correctly and still rejected? Work the remaining checklist before blaming the file: size cap (the most common second cause — see the 100KB guide), exact pixel dimensions, a file name with spaces or special characters that an old server rejects, and the possibility that the portal wants a PDF, not an image at all. Forms fail uploads for a handful of reasons, and format is only the first suspect. Eliminate them in order and the upload goes through.