How do you include a JWT in a fetch request?

Tests knowledge of the fetch options object and Bearer scheme syntax. A strong answer sets headers: { Authorization: Bearer <token> } as the second argument and notes fetch does not auto-attach tokens. Red flag: omitting Bearer or hardcoding secrets.
What's really being asked
This question tests whether you know how to configure a fetch request using the optional second argument and whether you understand the standard Authorization header format for bearer tokens. It also surfaces your awareness of security hygiene around JWTs and whether you treat fetch as an explicit, low-level API rather than expecting automatic credential handling.
The full answer
First, the candidate should show the options object passed as the second argument to fetch, including a headers property that maps to an object or Headers instance. Second, they should specify the Authorization header value using the Bearer scheme followed by a space and the token string. Third, they should note that fetch does not automatically attach authentication tokens, so every protected request must include this header manually or via a wrapper. Fourth, a senior candidate mentions security considerations such as never logging the token, avoiding query string transmission, and storing the token in memory or secure storage rather than localStorage when possible.
The mistakes people make
A red flag is omitting the Bearer prefix or misspelling Authorization. Another mistake is placing the token in the URL as a query parameter, which leaks it in server logs and browser history. Some candidates suggest modifying the fetch prototype or global defaults, which creates hidden side effects. Others forget that the headers live inside an options object, not as a third argument or a property on the URL string. Hardcoding a real token in the example code is also a subtle signal of poor security awareness.
What usually comes next
The interviewer may ask how you would refresh an expired token transparently, which leads to interceptors or wrapper functions. They might ask about CORS preflight behavior with custom headers like Authorization, which triggers an OPTIONS request. Another follow-up is how you handle token storage securely in a web application, comparing httpOnly cookies versus localStorage versus memory. They may also ask how to handle the case where fetch returns a 401 and whether you retry automatically.
A concrete example
A solid code sketch looks like this: define an async function fetchWithAuth that accepts a URL and a token. Inside, call fetch passing the URL as the first argument and an object as the second argument. Set the method if needed, then set headers to an object with Authorization set to the string Bearer concatenated with a space and the token. Await the response, check response.ok, and return the parsed JSON. This pattern keeps auth logic centralized and makes it easy to attach tokens to every outgoing request consistently.
Interview question
Which approach correctly attaches a JWT to a fetch request while following standard security and syntax practices?
- a.Set default headers on the global fetch prototype to automatically include the JWT on all requests
- b.Append the JWT to the URL as a query parameter so it is sent with every request to that endpoint
- c.Pass the headers object as a third argument to fetch after the URL and the method options object
- d.Provide an options object as the second argument with headers: { Authorization: 'Bearer ' + token }Correct
Why? this is the answer
fetch requires an options object as its second argument, and the Authorization header must use the Bearer scheme followed by a space and the token. Option A is tempting if you are used to interceptor patterns from libraries like Axios, but mutating the fetch prototype creates dangerous hidden side effects.
Just read this? Test yourself on what you have been reading.
Read the original → developer.mozilla.org
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles