Introduction

In JavaScript, an async function does not return a plain boolean immediately. It returns a Promise<boolean>, which means you must wait for the promise to resolve before you can tell whether the answer is true or false.

Why a Direct if Check Fails

This is the source of most confusion:

1async function isAllowed(userId) {
2  return userId === "admin";
3}
4
5const result = isAllowed("admin");
6console.log(result);

result is a promise object, not the final boolean. That is why this pattern is wrong:

if (isAllowed("admin")) {
  console.log("granted");
}

The if statement runs immediately and tests the promise object itself instead of the value that will arrive later.

Use await Inside Another Async Function

The cleanest solution is to call the async function from another async function and use await.

1async function isAllowed(userId) {
2  return userId === "admin";
3}
4
5async function run() {
6  const allowed = await isAllowed("admin");
7
8  if (allowed) {
9    console.log("access granted");
10  } else {
11    console.log("access denied");
12  }
13}
14
15run();

await pauses only the surrounding async function. It does not block the entire JavaScript runtime, which is why this style fits naturally into event-driven code.

Use .then When the Caller Is Not Async

If you are in code that is not marked async, or you prefer promise chaining, use .then.

1isAllowed("guest")
2  .then(allowed => {
3    if (allowed) {
4      console.log("granted");
5    } else {
6      console.log("denied");
7    }
8  })
9  .catch(error => {
10    console.error("check failed", error);
11  });

This does the same work as await, just in callback form.

false Is Not the Same as an Error

An async function can resolve to false, or it can reject with an error. Those outcomes should not be treated as identical.

1async function canPurchase(userId) {
2  const response = await fetch(`/api/can-purchase/${encodeURIComponent(userId)}`);
3
4  if (!response.ok) {
5    throw new Error(`HTTP ${response.status}`);
6  }
7
8  const data = await response.json();
9  return Boolean(data.allowed);
10}
11
12async function checkout(userId) {
13  try {
14    const allowed = await canPurchase(userId);
15
16    if (!allowed) {
17      console.log("blocked by policy");
18      return;
19    }
20
21    console.log("continue checkout");
22  } catch (error) {
23    console.error("unable to verify permission", error);
24  }
25}

A resolved false means the answer is no. A rejection means the check could not complete. Mixing those up can hide outages and backend bugs.

Running Several Checks Together

If you need several boolean results and the checks are independent, run them concurrently instead of awaiting one after another.

1async function isAllowed(userId) {
2  return userId.startsWith("a");
3}
4
5async function filterAllowedUsers(ids) {
6  const flags = await Promise.all(ids.map(id => isAllowed(id)));
7  return ids.filter((_, index) => flags[index]);
8}
9
10filterAllowedUsers(["anna", "bob", "amy"]).then(console.log);

This is both faster and clearer when order does not matter.

TypeScript Makes the Intent Clearer

If you are using TypeScript, declare the return type explicitly. That makes misuse harder because the caller sees immediately that a promise is involved.

async function isFeatureEnabled(name: string): Promise<boolean> {
  return name.length > 0;
}

Good naming also helps even in plain JavaScript. A function named fetchPermission is less likely to be mistaken for a synchronous boolean helper than one named isReadyNow.

Top-Level await and UI Event Handlers

In modern module-based environments, top-level await may be available. In browsers and UI frameworks, it is still more common to keep the async logic inside handlers or helper functions.

For example, inside a click handler you can call an async function and await the boolean before deciding what UI to show. The core idea stays the same: the value arrives later, so the code that depends on it must be asynchronous too.

Common Pitfalls

The most common mistake is branching on the promise object itself instead of awaiting the resolved value.

Another issue is forgetting to handle rejection. A network failure should not silently look like an ordinary false unless that fallback is intentional.

Developers also sometimes try to force JavaScript into synchronous waiting. In normal application code, the better pattern is to keep the control flow async and explicit.

Finally, do not serialize independent checks with repeated awaits unless the order actually matters.

Summary

• An async function returns a promise, not a raw boolean.
• Use await or .then to access the resolved value.
• Treat rejection separately from a business-logic false result.
• Use Promise.all for independent async checks.
• Clear naming and explicit types make async return values easier to use correctly.