MIME Types and File Extensions Reference for Web Upload Forms

Overview

A MIME type, also called a media type, describes the format of a resource. It normally has a type and subtype separated by a slash, such as image/png or application/pdf. A file extension, such as .png or .pdf, is only a name-based hint. The extension and MIME type often correspond, but they are not the same thing and should not be treated as interchangeable proof of file contents.

In an HTML upload form, MIME types are commonly placed in the accept attribute. This can guide the browser's file picker, but it does not replace server-side checks. A client can modify a request, omit a declared type, or send a file whose extension and contents disagree. Treat accept as a user-interface and workflow aid, not as a complete validation boundary.

The reference below lists commonly used values. For uncommon or newly introduced formats, verify the format's documentation and the media type registration or framework mapping used by your application. If no more specific value is available, a server may receive or assign application/octet-stream, which generally means “generic binary data.” It does not identify the file's exact format.

Common documents and text files

Images, archives, audio, video, and fonts

Checklist by scenario

When configuring an HTML file input

1. List the formats the workflow actually supports. Do not add broad types merely because a browser accepts them.
2. Use extensions for a clear, user-facing filter when that is easiest to understand.
3. Use MIME types when you want to describe a category, such as image/* or audio/*.
4. Test the picker on the browsers and operating systems your users rely on.
5. Explain rejected formats in visible text as well as in the accept attribute.

Examples:

<input type="file" accept="image/jpeg,image/png,image/webp">
<input type="file" accept=".pdf,.doc,.docx">
<input type="file" accept="audio/*">

These forms make different trade-offs. An explicit list is easier to audit, while a category such as image/* is more flexible. For a controlled import process, an explicit list is usually easier to align with documentation and server rules.

When handling multipart uploads on the server

• Read the submitted filename and declared content type as input data, not as conclusive identification.
• Compare the extension, declared MIME type, and—where appropriate—the file signature or parser result.
• Map accepted formats to an explicit application policy rather than accepting every value beginning with a broad category.
• Return an error that identifies the supported format without exposing internal parser details.
• Keep the same allowlist in the form, API documentation, server handler, and tests.

For a wider implementation workflow, see the file uploads in HTML, JavaScript, and APIs guide. If a valid file is being rejected, the file upload troubleshooting guide covers related request and transport problems.

When accepting developer files

Developer files can have overlapping or changing conventions. A JSON upload should normally use application/json, while a stylesheet uses text/css and an HTML document uses text/html. For configuration files with no universally reliable MIME mapping, document the accepted extensions and inspect the content according to the format your application supports.

What to double-check

• Extension aliases: .jpg and .jpeg represent the same common image family, so decide whether both should be accepted.
• Case handling: Users may provide .PDF or .PNG. Normalize extensions before comparison if your workflow is intended to be case-insensitive.
• Browser behavior: The accept attribute can influence a picker without guaranteeing identical filtering or presentation across browsers and devices.
• Missing declarations: A request may contain an empty or generic content type. Decide whether the server can identify the file through a trusted parser or should reject it.
• Generated downloads: If your application serves files back to users, configure the response's Content-Type deliberately instead of assuming the upload's declared value is correct.
• Framework mappings: Web servers, storage services, and application frameworks may maintain their own extension-to-MIME maps. Check the map used in the actual deployment path.

For security-sensitive upload decisions, use a dedicated implementation checklist rather than relying on this lookup table alone. The file upload security checklist provides that separate review context.

Common mistakes

Using the extension as proof

A filename ending in .pdf is not automatically a valid PDF. Renaming a file changes its extension but not its bytes. Use content-aware validation when the format matters, and keep file handling isolated from executable application paths.

Assuming accept blocks bad files

accept is advisory. It improves selection guidance but does not enforce an upload policy for direct API calls, scripted requests, or modified client requests. The server must apply the final rules.

Replacing a specific type with application/octet-stream

This generic value can be appropriate when a resource's format is unknown, but it is not a substitute for a known type. If your application knows that a file is JSON, PDF, or PNG, use the corresponding specific value.

Allowing a broad category without checking the workflow

image/* may include formats your image processor, thumbnail service, or downstream API does not support. Broad filters are convenient only when every accepted member is handled safely and consistently.

Testing only the happy path

Test valid files, renamed files, uppercase extensions, empty files, duplicate names, large files, and files selected from mobile devices. Record both the browser-side behavior and the server response. The file upload QA checklist can help turn these cases into repeatable tests.

When to revisit

Review your MIME type reference and upload allowlist whenever you add a file format, change a parser, replace a storage provider, update a framework, or change the browser-facing form. Revisit it before a seasonal planning cycle or a major product release if upload workflows are business-critical.

Also check for drift when users report that a valid file cannot be selected, when a browser displays an unexpected picker, or when an API starts returning application/octet-stream. Compare the form's accept value, the browser request, the reverse proxy or web server mapping, the application framework, and the final storage metadata.

Before shipping an update, use this short action list:

1. Write down each supported extension and its intended MIME type.
2. Update the HTML form, API contract, server allowlist, and user-facing help together.
3. Test from at least one desktop and one mobile workflow used by your audience.
4. Compare declared metadata with content-aware detection for representative files.
5. Record the decision and add a regression test for every newly supported or rejected format.

Keeping this list close to the implementation makes MIME type lookup a repeatable developer workflow rather than a one-time guess. For related markup checks, you can also run the HTML validator pre-launch check.