Free lesson · JavaScript Basic to Advance

The switch Statement

Easy5 min read

What Is a switch Statement?

A switch statement is JavaScript's way of comparing one value against many possible matches. It's a cleaner alternative to long chains of if/else if/else if/else when every branch is checking the same variable.

const day = "Wednesday";

switch (day) {
  case "Monday":
    console.log("Start of the week");
    break;
  case "Wednesday":
    console.log("Midweek");
    break;
  case "Friday":
    console.log("Almost the weekend");
    break;
  default:
    console.log("Some other day");
}

The switch evaluates the expression at the top (here, day). Then it compares the result against each case value. The first matching case runs. The break tells JavaScript to stop and skip the rest. The default block runs if no cases match.

switch is a tool you'll use occasionally, not constantly. It shines in specific situations and is awkward in others. Knowing when to reach for it — and when to stick with if/else — is part of the judgment that comes with writing JavaScript well.

When switch Is the Right Choice

switch works best when you're comparing one value against multiple specific possibilities, each leading to a clear action.

function getStatusMessage(statusCode) {
  switch (statusCode) {
    case 200:
      return "OK";
    case 201:
      return "Created";
    case 400:
      return "Bad Request";
    case 401:
      return "Unauthorized";
    case 404:
      return "Not Found";
    case 500:
      return "Server Error";
    default:
      return "Unknown Status";
  }
}

console.log(getStatusMessage(200));
console.log(getStatusMessage(404));
console.log(getStatusMessage(999));

This reads more cleanly than the equivalent if/else if/else chain. The structure is consistent — every case is "if the value equals X, do Y." There's no condition complexity, just direct value matching.

The visual rhythm helps too. Each case is its own line. Adding or removing cases is mechanical. If you have ten possible HTTP status codes to handle, a switch makes the code scan-readable in a way a long if/else if chain doesn't.

The break Keyword: Critical Detail

The break keyword is what tells JavaScript to stop after a matching case. Without it, execution falls through to the next case, then the next, until either a break is hit or the switch ends.

const number = 2;

switch (number) {
  case 1:
    console.log("One");
  case 2:
    console.log("Two");
  case 3:
    console.log("Three");
  default:
    console.log("Default");
}

That code logs "Two", "Three", and "Default". Because there's no break after the matching case 2, execution continues into case 3, then into default. This is called fall-through behavior and it's almost always a bug.

The fix is to add break after every case:

const num = 2;

switch (num) {
  case 1:
    console.log("One");
    break;
  case 2:
    console.log("Two");
    break;
  case 3:
    console.log("Three");
    break;
  default:
    console.log("Default");
}

Now this logs "Two" and stops. The break at the end of the matching case prevents fall-through. Forgetting break is one of the most common switch bugs in real codebases.

Intentional Fall-Through

Sometimes fall-through is what you want. When multiple cases should produce the same result, you can group them by stacking cases without break:

function describeDay(day) {
  switch (day) {
    case "Monday":
    case "Tuesday":
    case "Wednesday":
    case "Thursday":
    case "Friday":
      return "Weekday";
    case "Saturday":
    case "Sunday":
      return "Weekend";
    default:
      return "Invalid day";
  }
}

console.log(describeDay("Wednesday"));
console.log(describeDay("Saturday"));
console.log(describeDay("Hyphenday"));

Five cases stack together to produce "Weekday". Two cases stack to produce "Weekend". The fall-through is deliberate and useful — it's the cleanest way to express "any of these values lead to the same outcome."

When you do this, many style guides recommend a comment like // fall through to signal the intent, so a future reader doesn't think you forgot the break.

switch Uses Strict Equality

One detail worth knowing: switch compares values using ===, not ==. So case "5" does not match the value 5. Types must match exactly.

const value = 5;

switch (value) {
  case "5":
    console.log("matched string");
    break;
  case 5:
    console.log("matched number");
    break;
}

That logs "matched number". The case "5" doesn't match because the string "5" is not strictly equal to the number 5. This is consistent with the modern JavaScript guidance to prefer === over ==, but it can surprise developers who didn't realize switch worked that way.

When if/else Is the Right Choice

switch is awkward when the conditions involve anything more complex than equality. Range checks, multiple variables, complex expressions — these are clearer with if/else if:

const score = 72;

// This is clear with if/else if
if (score >= 90) {
  console.log("A");
} else if (score >= 80) {
  console.log("B");
} else if (score >= 70) {
  console.log("C");
} else {
  console.log("F");
}

// This is awkward with switch (you'd have to use 'true' as the expression)
switch (true) {
  case score >= 90:
    console.log("A again");
    break;
  case score >= 80:
    console.log("B again");
    break;
  case score >= 70:
    console.log("C again");
    break;
  default:
    console.log("F again");
}

The switch(true) pattern in the second version works, but it's an anti-pattern. It signals "I wanted a switch but my conditions don't fit the pattern, so I forced it." Just use if/else if for range checks. It's what they're designed for.

graph TD
    A[Need a multi-branch conditional] --> B{Am I comparing<br/>one value against<br/>specific possibilities?}
    B -->|Yes, equality only| C[Use switch]
    B -->|No, complex conditions| D[Use if / else if / else]

    style C fill:#10b981,color:#fff
    style D fill:#7c3aed,color:#fff

This diagram shows when to use switch versus if and else. Start by asking whether you're comparing one value against specific possibilities using only equality checks. If yes, switch is clean and readable. If your conditions involve ranges, multiple variables, or complex expressions, stick with if and else if chains.

Common Pitfalls

Warning: The traps with switch.

Forgetting break. Without break, execution falls through to the next case. This produces silently wrong behavior — your code runs more cases than you intended. Most linters can warn about missing break statements; turn that rule on.

Using == mental model with switch. Cases compare with ===. A case of 5 won't match the string "5". If your input might come from a form or an API as a string, convert it before the switch.

Forcing switch(true) for non-equality logic. When your branches need range checks or complex conditions, use if/else. The switch(true) trick technically works but signals confused intent.

Why This Matters in Interviews

Interview: Interviewers don't usually test switch directly. But your choice of switch versus if/else in a solution signals code judgment. Using switch for genuine multi-value matching is a positive signal — it reads cleanly. Using switch for complex conditions where if/else would be clearer is a small negative signal.

The other thing interviewers occasionally probe: do you know about fall-through? "What happens if you forget the break in a switch case?" is a quick check that you understand the mechanism.

Topic 4.6 — Interview Lens: Control Flow and Iteration Patterns — covers the broader interview treatment of control flow choices.

Try It

Exercise: Convert this if/else if chain into a switch statement. Then decide which version you find more readable:

function describeFruit(fruit) {
  if (fruit === "apple") {
    return "A red or green crunchy fruit";
  } else if (fruit === "banana") {
    return "A yellow soft fruit";
  } else if (fruit === "cherry" || fruit === "berry") {
    return "A small red fruit";
  } else if (fruit === "orange") {
    return "A citrus fruit";
  } else {
    return "Unknown fruit";
  }
}

Pay attention to how you handle the "cherry" and "berry" case — that's where the case-stacking pattern from earlier in this Topic comes in handy. Once you've written both versions side by side, pick the one you'd want a teammate to maintain.

Back to JavaScript Basic to Advance