FIELD NOTE 027TypeScriptReviewed July 2026

Format Number as Currency

Formats numbers as currency strings with locale support (no external libraries)

Copy the complete example or adapt its typed interface to your project. Comments are kept inside the snippet so the intent travels with the code.

pattern.ts
/**
 * Format number as currency string
 * @param amount Numeric amount
 * @param currency Currency code (default: 'USD')
 * @param locale Locale (default: 'en-US')
 * @returns Formatted currency string
 */
function formatCurrency(
  amount: number,
  currency = 'USD',
  locale = 'en-US'
): string {
  return new Intl.NumberFormat(locale, {
    style: 'currency',
    currency
  }).format(amount);
}

// Usage Example
console.log(formatCurrency(1234.56)); // $1,234.56
console.log(formatCurrency(1234.56, 'EUR', 'de-DE')); // 1.234,56 €
console.log(formatCurrency(1234.56, 'JPY', 'ja-JP')); // ¥1,235

Perfect for e-commerce applications, financial dashboards, or any app requiring localized currency formatting

Implementation note

Review the input assumptions and browser or runtime support before adopting a utility unchanged. Small helpers are easiest to maintain when their contract stays narrow.

How it works

Intl.NumberFormat applies locale-aware grouping, decimal, sign, and currency conventions using data built into the runtime. The formatter can be reused so repeated values follow one presentation policy.

What to watch for

Currency codes determine formatting but not exchange rates, tax, or accounting rules. Rounding options, minor-unit differences, unsupported locales, and floating-point money calculations require explicit decisions outside the formatter.

Production use

Use Intl for display after monetary values are represented safely, commonly as integer minor units or a decimal type. Keep business calculations separate and test negative, zero, large, and currency-specific values.

Before you ship

  • Confirm the input contract with tests that cover empty, invalid, boundary, and representative real-world values before sharing the helper across a codebase.
  • Keep the function focused on one responsibility and name any project-specific policy explicitly instead of hiding it inside a generic-looking utility.
  • Measure behavior in the browsers or runtime versions your product supports, especially when timing, storage, DOM state, locale, or network access is involved.
  • Document the return type, mutation behavior, failure mode, and performance characteristics beside the call site so future maintainers can evaluate changes safely.
  • Compare the example with current official platform documentation when it relies on a browser API, language feature, or runtime behavior that may change over time.
  • If the helper crosses a trust boundary, validate again on the server and avoid treating browser-side checks, TypeScript annotations, or formatted output as a security guarantee.
  • Add a small regression test whenever a real edge case is discovered; concrete examples preserve the reason behind a guard more reliably than a general comment.