How to use async/await with fetch in JavaScript
Łukasz Holeczek
Follow Łukasz Holeczek on GitHub
Connect with Łukasz Holeczek on LinkedIn
Follow Łukasz Holeczek on X (Twitter)
Using async/await with fetch is a common task when building modern javascript applications, especially when you need code that is easy to read and safe to reuse. As the creator of CoreUI and a developer with over 25 years of experience, I usually prefer the simplest built-in approach that stays explicit in real production code. Use async/await with the fetch() API to make HTTP requests in a clean, readable way without chaining .then() callbacks. This keeps the solution approachable while still being reliable enough for components, utilities, and data transformation logic. Below I will show the core snippet first, explain why it works, and point out the most important implementation detail to keep in mind.
Use async/await with the fetch() API to make HTTP requests in a clean, readable way without chaining .then() callbacks.
const fetchData = async (url) => {
const response = await fetch(url)
if (!response.ok) {
throw new Error(`HTTP error: ${response.status}`)
}
const data = await response.json()
return data
}
const users = await fetchData('https://jsonplaceholder.typicode.com/users')
console.log(users)
This approach declares the function as async, which allows you to use the await keyword inside it. The first await pauses execution until the HTTP response arrives, and the second await pauses until the response body is parsed as JSON. The result reads top to bottom like synchronous code, which makes it much easier to follow than nested .then() chains.
Why this works
The async keyword tells JavaScript that the function returns a promise. Inside it, await unwraps each promise so you can work with the resolved value directly. The browser still runs the request asynchronously under the hood, but your code reads in a linear, sequential style.
Common pitfall
The fetch() API does not throw on HTTP error status codes like 404 or 500. It only rejects on network failures. Always check response.ok or response.status before parsing the body, otherwise you may silently process an error page as if it were valid data.
Best Practice Note
This is the same kind of practical, low-complexity approach we prefer in CoreUI components to keep code predictable and easy to maintain.
Related answers
If you are working on similar problems, these guides are good follow-ups:
- How to handle async/await errors
- How to use try/catch in JavaScript
- How to generate a random number in JavaScript
