Date Formatter

The Date Formatter turns a date from any source into a string in any format — ISO 8601 for APIs, US mm/dd/yyyy or European dd/mm/yyyy for forms, custom strftime patterns for reports, locale-specific long-form for documents. Every developer who has ever shipped a product that displays dates has hit this problem repeatedly: the backend returns a Unix timestamp, the design system specifies \"Jan 15, 2024\", the German version needs \"15. Januar 2024\", the legal doc needs \"the 15th day of January, 2024\". This tool shows every common format simultaneously from one input date.

Input flexibility is a key feature. Paste a Unix timestamp (seconds or milliseconds), an ISO 8601 string, a US date, a European date, or an arbitrary human string like \"January 15 2024\" — the parser figures it out. Output includes the standard formats (ISO 8601, RFC 2822, US, European, Japanese, weekday name, month name, ordinal day) plus a custom format field where you can enter strftime tokens (%Y-%m-%d, %B %d, %Y, %A) to produce any pattern you need. Timezone-aware — specify the source timezone and output timezone to handle cross-region formatting. All formatting runs in your browser using the same locale data browsers use everywhere, so results match what users see in their apps.

Date formatting divides into two operations: parsing a source string into an internal date-time representation, and formatting that representation into a target string.

Parsing is the harder problem because date formats are ambiguous. Is 03/04/2024 March 4 (US) or 4 March (Europe)? The parser applies heuristic rules: ISO 8601 first (unambiguous), then inspects the input for format hints. If the first number is greater than 12, it is the day (European); if unambiguous (e.g., 15/03/2024), treat as day-month-year. For safety, the parser reports which interpretation it chose and lets you override.

Internal representation uses a UTC instant plus an optional source timezone. This lets the formatter output the same moment in multiple timezones without recomputing the parse.

Output formatting uses either the browser\u2019s Intl.DateTimeFormat API for locale-aware standard formats, or a strftime-style token processor for custom patterns. Supported tokens include: %Y 4-digit year, %y 2-digit year, %m 2-digit month, %B full month name, %b short month name, %d 2-digit day, %j day of year, %A full weekday, %a short weekday, %H 24-hour hour, %I 12-hour hour, %M minute, %S second, %p AM/PM, %Z timezone abbreviation, %z timezone offset.

Locale handling is critical for international output. Germany uses \"15. Januar 2024\"; France \"15 janvier 2024\"; Japan \"2024年1月15日\"; Arabic right-to-left with Eastern Arabic numerals. The tool uses the browser\u2019s locale data (same data every app gets via Intl), so formatted output is correct for over 100 locales.

ISO 8601 deserves specific mention because many developers get it wrong. The canonical form is YYYY-MM-DDTHH:mm:ss.sssZ for UTC, or YYYY-MM-DDTHH:mm:ss.sss±HH:MM for offsets. Spaces instead of T are tolerated by some parsers but not standard. The Z suffix means UTC; omitting it leaves the timezone implicit (and therefore dangerous).

RFC 2822 is the email-style format (\"Mon, 15 Jan 2024 09:30:00 +0000\") still seen in HTTP headers and some legacy APIs. It is less consistent than ISO 8601 but remains in active use.

Compared to writing date formatting code in your application language, this tool gives instant preview of how a format will look without needing to run code. For production use, the formatting still needs to be in code; the tool is for exploration and verifying format strings.

Compared to moment.js, date-fns, or Luxon, this tool uses the browser\u2019s Intl API directly — the same data those libraries eventually use. For client-side formatting, no library is really needed; for server-side or complex date arithmetic, a library adds consistency across platforms.

Compared to spreadsheet date formatting, this tool handles more formats and supports strftime tokens rather than Excel\u2019s limited code list. For bulk formatting of many rows, a spreadsheet still wins; for exploring formats or producing a single formatted string, this tool is faster.