/^/
EasyFiles4 min read

MIME Type Regex

Matches a MIME type string in the form type/subtype, such as text/html or application/json, including structured suffixes like +json.

#mime#content-type#files#validation#http

Regex Pattern

^[a-zA-Z0-9!#$&^_.+-]+\/[a-zA-Z0-9!#$&^_.+-]+$

Pattern Breakdown

Hover over a token to see what it does.

^[a-zA-Z0-9!#$&^_.+-]+\/[a-zA-Z0-9!#$&^_.+-]+$
TokenMeaning
^Anchors the match to the start of the string
[a-zA-Z0-9!#$&^_.+-]+The top-level type (e.g. text, application, image), made of RFC 6838 token characters
\/Literal slash separating type and subtype
[a-zA-Z0-9!#$&^_.+-]+The subtype (e.g. html, json, svg+xml), using the same allowed token characters
$Anchors the match to the end of the string

Detailed Explanation

What it does

This pattern validates that a string has the two-part type/subtype shape defined for MIME (Internet media) types, such as text/html, application/json, or image/svg+xml, without allowing extra slashes or empty segments.

Why it works

The character class [a-zA-Z0-9!#$&^_.+-] reflects the 'restricted-name-chars' allowed in MIME type and subtype tokens per RFC 6838, including the plus sign used for structured syntax suffixes like +json or +xml. Requiring exactly one literal slash between two non-empty token groups, anchored at both ends, ensures the whole string is a single well-formed type/subtype pair rather than a partial or multi-segment path.

Common use cases

  • Validating a Content-Type header value before routing or parsing a request body
  • Checking user-supplied or configuration-driven MIME type strings for file upload allowlists
  • Filtering a list of supported formats to ensure each entry is a syntactically valid MIME type
  • Parsing structured syntax suffixes (e.g. application/vnd.api+json) to detect the underlying serialization format

Edge cases

  • Vendor and structured types like application/vnd.api+json or image/svg+xml are matched because + and . are included in the token character class
  • A string with no slash, like just 'text', is rejected since the pattern requires both a type and subtype
  • A string with an extra segment, like text/html/extra, is rejected because the subtype group cannot contain a slash
  • An empty type or subtype, such as /html or text/, is rejected since both groups require at least one character
  • MIME type parameters like charset, e.g. text/html; charset=utf-8, are not part of the base pattern and would cause the match to fail if included

Limitations

  • Does not validate MIME type parameters such as ; charset=utf-8 that often follow a Content-Type value
  • Does not check the type/subtype pair against the IANA registry of officially recognized MIME types
  • Case sensitivity is not enforced by convention (MIME types are typically lowercase), and this pattern accepts uppercase letters too

Interactive Tester

Edit the pattern or text below — matching runs live in your browser.

text/html application/json image/svg+xml

Test Cases

Editable — add your own inputs to see if they pass.

InputExpectedResult
Pass
Pass
Pass
Pass
Pass
Pass
Pass
Pass

Language Variants

Production-ready examples in 12 languages.

const mimeTypeRegex = /^[a-zA-Z0-9!#$&^_.+-]+\/[a-zA-Z0-9!#$&^_.+-]+$/;
console.log(mimeTypeRegex.test('application/json')); // true

Common Mistakes

Validating a full Content-Type header including parameters, like 'text/html; charset=utf-8', against this pattern and getting a false negative

Fix: Strip or split off the parameter section (everything after the first ;) before validating the base MIME type

Using a wildcard .+ for the subtype, which allows an embedded slash and lets malformed multi-segment strings pass

Fix: Use a character class that excludes / explicitly, such as [a-zA-Z0-9!#$&^_.+-]+, so the subtype can't itself contain a slash

Forgetting that structured suffixes use +, causing patterns without + in the character class to reject valid types like image/svg+xml

Fix: Include + in the allowed character set for both type and subtype

Performance Notes

  • Both character classes are simple and bounded by the literal slash, so there is no ambiguity or backtracking risk
  • Anchoring with ^ and $ ensures the whole string is validated in a single linear pass
  • For validating many MIME types against an allowlist, prefer a Set lookup after a light-weight shape check rather than repeated regex evaluation

Browser Compatibility

EngineSupportedNotes
ChromeYes
FirefoxYes
SafariYes
EdgeYes
Node.jsYes