When WordPress rejects a file type, check its actual format and the specific uploader’s requirements. Renaming an extension does not convert its contents. Choose a publishing format suited to readers, then verify that the media library or plugin field accepts and handles it correctly.
Guide reviewed: October 8, 2026. Interface labels may vary by version, account and device.
Quick diagnosis
| Situation | Check | Useful action |
|---|---|---|
| Design source renamed to JPG | Actual file contents | Export a real image from the original application |
| Plugin field rejects a media-library format | That field’s allowed types | Follow the feature’s requirement |
| Known-good accepted format also fails | Uploader and network policy | Report the controlled comparison |
| Specialist format needed | Validation and reader workflow | Developer review of the intended format only |
Check what the file actually contains
WordPress provides checks for filenames and file types, including a function intended to determine a file’s real type. A name alone is not the whole story. A file exported incorrectly or given an unrelated extension may not match what the uploader expects.
Open the original in the application that created it and use its normal export option when you need a different format. For an article image, for example, export a suitable image file rather than renaming a design-project file to end in .jpg.
For a downloadable document, decide whether readers need an editable source or just a readable copy. A properly exported PDF may suit a finished handout, while a template may need a supported editable format. Choose according to the reader’s task, not merely according to which filename passes the upload screen.
Check the rules of this particular uploader
Use a format the field explicitly accepts. Compare a small known-good file with the rejected original and note which uploader was used. Managed network settings and feature-level restrictions may differ from the media library’s rules.
The WordPress media library and a plugin’s upload field may have different requirements. A form that accepts only PDFs can reject an image that the media library would accept. Read the instructions beside the field and the documentation for that feature.
If the site is part of a managed network, ask its administrator about the allowed types. An individual editor may not control the network’s policy. A rejection in that environment should not be treated as a reason to alter unrelated server settings.
Try a small, known-good example of the format the field says it accepts. If it works, compare the original file’s format and export process. If it also fails, report that comparison to the maintainer.
Decide whether the format is necessary
Before extending the allowed list, consider what the visitor will do with the file and how the website will handle it. A less familiar format may need a specific viewer, download workflow, or processing tool. Accepting the extension does not provide those features automatically.
For example, a design source file intended for a small authorized team may belong in an appropriate private document-sharing system. A public article illustrating the same design may only need an exported image. Those are different publishing needs.
Some formats can contain active content or other material that requires additional care. Ask the developer how the intended upload will be validated and served. Do not enable unrestricted uploads just because one needed file was rejected.
For developers, allow only the intended type
WordPress documents the upload_mimes filter for modifying allowed MIME types. A developer using it should specify the legitimate formats needed by the feature and check their actual handling. A copied snippet allowing everything is too broad for a single publishing requirement.
The developer should also confirm whether another plugin or the hosting environment imposes its own rules. A change in one list may not affect the uploader that produced the message. Keep the correction tied to that specific path.
Test with a valid file and an unsuitable file in a controlled environment. The useful outcome is that the intended format works while inappropriate uploads remain rejected. Removing the error for every file is not the goal.
Check the reader’s experience
Open the uploaded file using its intended public or authorized link. Confirm the format, filename and application needed to use it. A finished handout might suit PDF; an editable template needs a supported source format. Choose from the reader’s actual task.
Once the upload succeeds, open the file from its public or authorized download link. Confirm that it displays or downloads as intended, has a clear filename, and can be used in the application readers are likely to have.
For an image, check its appearance in the article preview. For a document, include a brief description of the format and what the reader can do with it. This makes the successful upload useful rather than leaving visitors to guess.
Keep the chosen format and any deliberate upload-policy change in your site notes. The next editor can then follow the intended workflow instead of repeatedly renaming files or adding another broad upload exception.
References: WordPress’s file-type check and its allowed MIME-type filter.
Confirm intended files work and unsuitable files stay rejected
For a deliberate policy change, have the developer test the intended valid format and an unsuitable file in a controlled environment. Record the uploader, format and reason for the decision. Keep unrestricted upload exceptions out of a solution for one specific publishing need.