SQL MIME Type – Free, Online, Private
application/sql is the RFC 6922 type for a SQL script. The header does not say which database dialect the script is.
What .sql is
A .sql file is source text: statements, comments, and often a mix of DDL and data. RFC 6922 registers application/sql. The registration does not name a dialect. A script for PostgreSQL and a script for MySQL can share the type and still fail on the other engine because of quoting, types, and vendor syntax. The body is text. Send charset=utf-8. There is no magic number. A file that starts with -- or with CREATE is SQL only because a human or a parser says so.
IANA registers application/sql in RFC 6922. The media type is application/sql. Extensions that use it on this page: .sql. A client compares the type, not the filename, once the response has arrived. The filename still matters on disk and in Content-Disposition, which is why a wrong extension and a wrong header are two different bugs.
What sends application/sql
What sends application/sql: Send application/sql; charset=utf-8 when you distribute a schema or a migration as a download. An API that runs a query should not echo the script back with this type and a 200 if the interesting result is rows. Rows belong in application/json or text/csv. The script type is for the script. Set Content-Disposition with a filename when the URL does not end in .sql. Do not execute a script because the Content-Type said application/sql. That is the same class of bug as executing a file because it was named .sql. The file on disk is still .sql. Once the response exists, a client trusts application/sql, not the filename. If you publish both a SQLite database and the SQL that built it, the database is application/vnd.sqlite3 and the script is application/sql. They are different files. Replacing one with the other under a stable URL will break a client that cached the type with the bytes.
Content-Type for .sql
Send application/sql; charset=utf-8. The charset parameter names the encoding of the body. Leaving it off forces the client to guess, and for several text types the registered default is not UTF-8. Do not send a charset on a redirect. The header belongs on the response that contains the bytes.
Content-TypeContent-Type: application/sql; charset=utf-8
nginx, Apache, and Express
These snippets map .sql to application/sql. nginx reads the types block when it picks a type from the URL's extension. A location that sets default_type, or an application that sets the header itself, overrides that map. Apache AddType applies in the directory context where you put it. The Express static example writes the header for files ending in .sql so a stale mime database in the framework cannot disagree with the type on this page.
nginx# /etc/nginx/mime.types, inside the types { } block
application/sql sql;
charset utf-8;
charset_types application/sql;
ApacheAddType application/sql .sql
AddCharset UTF-8 .sql
Expressimport express from "express";
const app = express();
app.use(express.static("public", {
setHeaders(res, filePath) {
if (filePath.endsWith(".sql")) {
res.setHeader("Content-Type", "application/sql; charset=utf-8");
}
},
}));
Pitfalls for application/sql
Pitfalls that show up for application/sql, and not for a neighboring type with a similar extension: The dangerous bug is an upload endpoint that runs whatever SQL the body contains because the type matched. Authenticate and review migrations out of band. Another bug is a dump that contains COPY data or inserts with binary blobs, labeled application/sql and then altered by a text middleware that normalizes newlines. The dump no longer restores. Another is a BOM or a smart quote inserted by an editor, which makes the first token invalid. Another is serving the script as text/html so a browser renders a table-like accident from the angle brackets you do not have, or sniffs a document. Use the SQL type and nosniff if the script is user-supplied.
- application/sql does not identify PostgreSQL, MySQL, SQLite, or SQL Server. Say the dialect beside the URL.
- text/x-sql is unofficial. RFC 6922's type is application/sql.
- A migration tool's journal is data about scripts. It is not itself application/sql unless it is a script.
- Gzip is appropriate for a large dump. Keep the type and set Content-Encoding.
Frequently asked questions
Does application/sql pick a dialect?
No. RFC 6922 registers the type for SQL text in general. The dialect is part of your contract, not the header.
Should I send a charset?
Yes. application/sql; charset=utf-8. The script is text.
Is text/x-sql acceptable?
It is an unofficial alias. Send application/sql.
Should an API return query results as application/sql?
No. Return the rows as JSON or CSV. application/sql describes a script, not a result set.