Format JavaScript Online: JS Beautifier

The Formatted Code

Applying the formatter to the minified JavaScript above produces:

const calculateTotal = (items, discount) => {
  let total = 0;
  for (const item of items) {
    total += item.price * item.quantity;
  }
  if (discount > 0) {
    total = total * (1 - discount / 100);
  }
  return Math.round(total * 100) / 100;
};

const formatCurrency = (amount) =>
  new Intl.NumberFormat("en-US", {
    style: "currency",
    currency: "USD",
  }).format(amount);

async function fetchProducts(category) {
  const response = await fetch(`/api/products?category=${category}`);
  if (!response.ok) {
    throw new Error(`HTTP ${response.status}`);
  }
  const data = await response.json();
  return data.products
    .filter((p) => p.inStock)
    .sort((a, b) => a.price - b.price);
}

export { calculateTotal, formatCurrency, fetchProducts };

Each statement gets its own line. Arrow function bodies are broken across lines when they exceed the print width. Trailing commas are added to multi-line constructs for cleaner diffs.

Why JavaScript Formatting Matters

Unformatted JavaScript is a maintenance burden. A minified one-liner works when you write it, but becomes unreadable the moment someone else needs to modify it. Formatting makes several things faster:

Code review. A reviewer can check function logic, argument destructuring, and control flow independently when each statement is on its own line. A single-line function requires mentally parsing the entire string to verify any part of it.

Debugging. When a function returns wrong results, you usually isolate the problem by adding console.log statements or commenting out lines. Properly formatted code makes that process straightforward.

Pull request diffs. A change to one condition should show as a single changed line in a diff. In a minified file, any change touches the entire line, making the diff useless for review.

Prettier Style Decisions

The formatter uses Prettier’s opinionated defaults. These are not configurable in this tool, but they cover the most common conventions:

Semicolons: Always added. This prevents ASI (automatic semicolon insertion) bugs that are difficult to debug.

Quotes: Double quotes for strings. This is Prettier’s default and avoids escaping when strings contain apostrophes.

Trailing commas: Added to multi-line arrays, objects, and function parameters. This produces cleaner git diffs because the last element can be changed without adding a comma to the previous line.

Indentation: 2 spaces. This is the most common convention in JavaScript projects and matches the default in most linters and editors.

Print width: 80 characters. Lines that exceed this are broken at logical points (after arrows, before operators, at argument boundaries).

When Not to Use Prettier

Prettier is a code formatter, not a linter. It does not catch bugs, enforce best practices, or flag unused variables. Use ESLint for that. Prettier also does not handle code organization: it will not move functions between files, reorder imports (unless configured with a plugin), or restructure your module system. Some code styles are genuinely better than Prettier’s defaults for specific use cases: tabs for indentation, single quotes, no semicolons. If your project has an established style that differs from Prettier’s defaults, configure Prettier accordingly or use a different formatter.