GraphQL defines no file type, so how does a client send a file with an operation?

## Nothing in the specification carries bytes The GraphQL specification defines five built-in scalar types — `Int`, `Float`, `String`, `Boolean` and `ID` — and none of them is binary. The specification also says nothing about HTTP at all. The GraphQL over HTTP working draft, which does, describes a request whose body is JSON. JSON has no byte type. That is the whole reason this question exists, and it is the sentence to lead with in an interview: a file has to reach the server either **encoded into a JSON value**, or **outside the JSON body entirely**. Every real technique is one of those two, and there are three in common use. ## Route one: base64 into a String variable Declare the variable as `String!` and send the file base64-encoded. No server feature is required and no convention has to be agreed — it is an ordinary operation with an unusually long string in it. The costs are arithmetic. Base64 inflates the payload by about a third. The whole encoded file exists as a single string in the client's memory, in the request body, in the server's parsed variables, and in anything downstream that records variables — a log line, a trace attribute, an error report. Nothing streams: the server cannot begin doing anything with the file until the last byte of the JSON body has arrived and been parsed. For a 4 KB signature capture or a small SVG this is genuinely the right call, and saying so is a better answer than reflexively reaching for machinery. For a 380 MB master scan it is not. ## Route two: the GraphQL multipart request specification This is a **community specification**. It is not part of the GraphQL specification, it is not part of the GraphQL over HTTP working draft, and it is not published by the GraphQL Foundation — candidates who say "GraphQL supports file uploads" are usually thinking of this and are usually wrong about its status. It describes sending the request as `multipart/form-data` with three kinds of field: - `operations` — the JSON operation, with `null` at every variable position a file will occupy; - `map` — a JSON object binding each numbered file field to the variable path where its bytes belong; - the file fields themselves, one per file. The server decodes the two JSON fields, substitutes each uploaded file into the variables at the mapped paths, and then executes the operation exactly as it would any other. The response is an ordinary GraphQL JSON response with `data` and `errors` — nothing about the reply is special. Servers that implement the convention conventionally declare a custom scalar named `Upload`, used only in **input** positions. No specification names that scalar. It has no literal form — you cannot write a file into a document — so a file always arrives through a variable. And what the resolver actually receives when it reads that argument differs by server: a readable stream, a temporary file path, a byte buffer, a lazily-opened handle. The SDL looks portable across servers; the resolver body is not. The headline benefit is that the file and its metadata arrive in **one mutation**, authorized by the same field authorization as any other mutation, validated together, and either committed together or not at all. ## Route three: upload out of band and pass a reference The bytes never enter the graph's request path. A mutation returns a short-lived signed URL scoped to one storage key; the client sends the bytes directly to the storage service over ordinary HTTP; a second mutation attaches the stored object to the domain record by its identifier. Three round trips instead of one, and a two-phase state to manage — but the graph stays a JSON-only API, and file size stops being the graph's problem. ## Choosing between them A museum collection graph makes the split concrete. A 240 KB condition photo attached to an accession record rides comfortably with its mutation: one request, one authorization decision, one transaction, and the photo is never stored without the condition report that explains it. A 380 MB master scan from the digitisation bench does not: it wants to go straight to storage, it wants to be retryable, and no request path in the graph should be holding it. ## What an interviewer is listening for Three things. That you know the specification defines nothing here. That you can name the multipart convention as a **convention** and describe roughly how it binds bytes to a variable. And that you treat the choice as a size-and-lifecycle trade rather than a default. The weakest answer is "you just use the `Upload` scalar" — it names a server convention as though it were a language feature, and it does not survive the next question, which is what happens when the file is a gigabyte.