How Automatic MIME Type Detection Works on AIOZ Storage

Automatic MIME type detection on AIOZ Storage sets an object's Content-Type from the file's bytes when your upload doesn't send one. If you do send a Content-Type header, AIOZ Storage stores your value instead. Google's Magika model does the detection, and unsure results fall back to application/octet-stream.

TL;DR:

• AIOZ's docs give a strict order: your Content-Type header wins, and content detection runs only when the header is missing.
• Detection uses Google Magika, which reads the file's bytes instead of trusting its extension. If it can't decide with confidence, AIOZ Storage stores application/octet-stream.
• Your client decides which branch you get. In our Nov 4, 2026 test, boto3 sent no Content-Type, while the JavaScript SDK sent application/octet-stream on its own.

Updated Nov 4, 2026: checked every claim against AIOZ's MIME type detection docs page, added the octet-stream fallback, a test of what boto3 and the JavaScript SDK send, how extension, content and browser detection differ, and a flow diagram.

How Does AIOZ Storage Decide an Object's MIME Type?

AIOZ's MIME type detection docs describe one order of precedence for S3-compatible uploads, and it has two branches:

1. If your upload request includes a Content-Type header, AIOZ Storage uses that value as the object's MIME type.
2. If it doesn't, AIOZ Storage analyzes the file content and picks the most likely type.

The docs add a fallback: when the type can't be determined with confidence, the object gets application/octet-stream. The final type is stored with the object's metadata and used when the object is served later. All of this runs at upload time, so you get the result as soon as the upload finishes.

The rule never checks or corrects a header you sent, so a PNG uploaded with Content-Type: text/plain stays text/plain on AIOZ Storage. AIOZ announced the feature on May 19, 2026 (AIOZ announcement), and the docs page above is the current reference for how it behaves.

What Does a Wrong MIME Type Break?

The MIME type tells a browser, a CDN or any HTTP client what to do with the bytes it receives. MDN describes application/octet-stream as the default for binary files: browsers usually treat it as a download and show a "Save As" dialog (MDN MIME types guide). So an image stored with that type downloads instead of showing on your page, and a PDF saves instead of opening in the viewer.

For text, MDN says text/plain is the default, and browsers will display it. That's fine for a log file, but a JSON API response served as text/plain can trip a client that checks for application/json. A stylesheet or script with the wrong type can also be blocked when a site sends X-Content-Type-Options: nosniff.

Object storage makes these mistakes easy, because a bucket only sees bytes under a key. S3 clients don't have to send a Content-Type, and in our test below boto3 sent none, so the type you end up with depends on your upload code.

Which Uploads Trigger Automatic Detection?

Detection runs only when the header is missing, so your client library decides whether you ever reach it. We checked two popular SDKs on Nov 4, 2026. Each one sent an upload with no type set to a local HTTP server, which recorded the Content-Type header, and this is the real output:

boto3 1.43.123, put_object, no ContentType      -> (no Content-Type header)
boto3 1.43.123, upload_file, no ContentType     -> (no Content-Type header)
client-s3 3.1161.0, PutObjectCommand, no type   -> application/octet-stream
both SDKs, ContentType set to image/png         -> image/png

What that means for you depends on the SDK your upload code uses:

• With boto3, an upload without ContentType sends no header, so AIOZ Storage's detection runs on the file content.
• With the AWS SDK for JavaScript v3, the SDK fills in application/octet-stream. Under the documented order, a header that is present is used, so the object would be stored as application/octet-stream and detection wouldn't run. Set ContentType yourself in JavaScript.
• With the AWS CLI, aws s3 cp guesses the type from the file name by default and sends it, unless you pass --no-guess-mime-type (AWS CLI reference; not run here). So detection only runs for the CLI when you turn the guess off.

We tested the headers each client sends, not the type AIOZ Storage stored, because that needs real keys. If you rely on detection in production, upload a test file and check the stored Content-Type with a HEAD request first.

Extension, Content and Browser Sniffing

There are three common ways to work out a file's type when nobody states it, and they fail in different ways. A service can guess from the file name. Alibaba Cloud's OSS docs, for example, say that a missing Content-Type is set from the object name's extension, with application/octet-stream when there is no extension. That's fast, but a missing or wrong extension gives you a wrong answer.

A browser can sniff the type at download time. MDN calls this MIME sniffing and notes that each browser does it differently, so the same file can behave differently from one browser to the next. Detection from content at upload time, the approach AIOZ Storage takes, reads the bytes once and stores one answer that every client sees.

What's Running Underneath: Google Magika

AIOZ's docs name the engine: Google Magika, an open-source file type detector built on deep learning. Instead of trusting the extension, it reads the file's bytes, which helps with files whose extensions are missing, generic or misleading. Google's README gives these numbers for the model and how Google uses it:

• The model weighs only a few MB, and inference takes about 5 ms per file on a single CPU once the model is loaded.
• Google trained and tested it on about 100M samples across more than 200 content types, with about 99% average accuracy on its test set.
• Inference time is close to constant whatever the file size, because Magika reads only a limited part of each file.
• Google uses it at scale to route Gmail, Drive and Safe Browsing files to the right security and content scanners.

Magika's design fits the fallback in AIOZ's docs. It has a confidence threshold for each content type, and below that threshold it returns a generic label, such as "Unknown binary data", rather than a guess. On the storage side, AIOZ's docs say an object whose type can't be determined with confidence gets application/octet-stream.

How AIOZ Storage Handles Content-Type

In practice, you choose which branch each upload takes. Set ContentType on every upload where you know the type, such as files your app generates. Let detection handle user uploads with unreliable names, and use a client that leaves the header out when you want it to run. Our JavaScript SDK quickstart for AIOZ Storage shows where ContentType goes in a PutObjectCommand.

What the docs don't cover yet:

• Whether objects stored before May 19, 2026 were scanned again.
• How to change the type of an object you already stored, for example by copying it over itself with new metadata.
• Whether an application/octet-stream header sent by a client counts as "provided" or triggers detection.

Next step: read AIOZ's MIME type detection page for the full order of precedence.

Frequently Asked Questions

What is automatic MIME type detection on AIOZ Storage?
It's an upload-time fallback that sets an object's MIME type from the file's content, using Google Magika, when the upload doesn't include a Content-Type header.

Does AIOZ Storage override a Content-Type I set myself?
No. AIOZ's docs say a Content-Type header you send is used as the object's MIME type, correct or not.

What happens if AIOZ Storage can't tell the file type?
It stores application/octet-stream, the generic binary type that browsers usually offer as a download.

What is Google Magika?
It's Google's open-source, deep-learning file type detector. Its README reports about 5 ms per file on one CPU and about 99% average accuracy across more than 200 content types.

Why would an upload have no Content-Type?
S3 clients don't always send one. In our test, boto3 sent no header when the code didn't set ContentType, so many Python scripts upload without one.

Does detection run for uploads from the AWS SDK for JavaScript?
Not by default, going by the documented rule. The SDK sent application/octet-stream in our test, and a header that is present is used as-is, so set ContentType yourself.

Where does the detected MIME type get stored?
In the object's metadata, the same place a type you send would go. AIOZ Storage uses it when it serves the object later.

Does this apply to objects uploaded before the feature shipped?
AIOZ's docs and announcement describe upload-time behavior only, and neither mentions a scan of objects stored before May 19, 2026.

Related Reading

• What Is S3 Object Storage? How It Works, Explained: the object and key model that MIME type sits on as metadata.
• AIOZ Storage JavaScript SDK Quickstart with client-s3: where to set ContentType in JavaScript uploads.
• File Management API with FastAPI, Boto3, and AIOZ Storage: a boto3 upload path where you choose whether to send the type.
• How to Rename a File in an S3 Bucket on AIOZ Storage: what you can change about an object after upload, and what you can't.
• S3 Multipart Upload Explained, From Part Size to Cleanup: the other S3 upload path, where the type is set when the upload starts.
• AIOZ Storage Developer Platform with SDKs, CLI, and MCP: every upload path (SDKs, CLI, direct API) this behavior applies to.
• How to Use AIOZ Storage Effectively: A Practical Checklist: other setup details to get right before you upload real data.
• Object storage glossary: short definitions for Content-Type, object metadata and related terms.

References

• AIOZ Storage Documentation: Automatic MIME Type Detection
• AIOZ Network: Automatic MIME Type Detection Now Available on AIOZ Storage
• Google Magika on GitHub
• MDN: MIME types (IANA media types)
• AWS CLI Command Reference: s3 cp
• Alibaba Cloud OSS: Configure the Content-Type header