Date Format Converter Online — Convert Between 20+ Formats

Translate any date between ISO 8601, US (MM/DD/YYYY), EU (DD/MM/YYYY), SQL, RFC 2822, Unix epoch, and 20+ other formats — including custom strftime patterns. Bulk mode for CSV columns. 100% browser.

Selected target

Paste a date above to convert.

Renders every supported format once you paste a date.

What is a Date Format Converter?

A date format converter takes a date written in one representation — ISO 8601, US slashes, EU slashes, SQL, RFC 2822, Unix epoch — and re-emits it in another. It is the bridge between systems that disagree on how a date should look on the wire.

The OpenFormatter converter ships with 20+ built-in formats and a custom strftime pattern field for anything else. It auto-detects the source if you cannot tell, lets you force a hint when ambiguous (1/2/2026 — US or EU?), and runs every parse and render entirely in the browser. Bulk mode chews through CSV columns without uploading a byte.

How to convert a date format online — 4 steps

  1. Paste the date. Drop the source string into the input. Choose a source-format hint when the string is ambiguous (1/2/2026); leave it on Auto-detect for clean ISO or epoch values.
  2. Pick the target format. 20+ presets cover ISO 8601, US, EU, SQL, RFC 2822, Unix epoch (s and ms), long English, compact, German, log style, and time-only. Pick Custom strftime for anything bespoke.
  3. Read the result. The selected target shows alongside a complete reference table of every format — handy when you need a second representation for a different tool.
  4. Bulk mode for CSV. Switch to Bulk, paste a CSV date column, and every row converts using the same source/target settings — perfect for ETL cleanup.

Sample input and output

Input:  2026-04-30T12:34:56Z

ISO 8601 (UTC):     2026-04-30T12:34:56.000Z
US (MM/DD/YYYY):    04/30/2026
EU (DD/MM/YYYY):    30/04/2026
SQL:                2026-04-30 12:34:56
RFC 2822:           Thu, 30 Apr 2026 12:34:56 GMT
Unix seconds:       1777984496
Long English:       Thursday, April 30, 2026
German:             30.04.2026
Custom %Y/%m/%d:    2026/04/30

20+ Built-in Formats

ISO 8601, US, EU, SQL, RFC 2822, Unix epoch (seconds/ms), long and short English, German, compact, log style, and time-only — all included.

Custom strftime

Drop in any strftime pattern (%Y-%m-%d %H:%M:%S) for the formats not covered by presets. Same syntax as Python, C, Ruby, and PostgreSQL.

Bulk CSV Mode

Paste a CSV column and convert every row in one shot. Output is a copy-ready table — perfect for ETL cleanup before loading.

Common use cases

  • check_circleConverting a CSV export from US format (MM/DD/YYYY) to EU format for a European client
  • check_circleTranslating Excel-exported dates to SQL TIMESTAMP for database import
  • check_circleConverting Unix epoch column from a server log into ISO 8601 for a JSON API
  • check_circleReformatting RFC 2822 email-Date headers into ISO 8601 for analytics
  • check_circleProducing a long-English date string for a marketing email or invoice PDF
  • check_circleGenerating a compact YYYYMMDD identifier from an ISO date for filenames
  • check_circleConverting between strftime, Moment.js, and date-fns format strings
  • check_circleCleaning a CSV column of mixed formats into one canonical representation

Why store dates in ISO 8601 even when displaying them differently?

Mixing display format with storage format is the root cause of nine out of ten production date bugs. Store the canonical form (2026-04-30T12:34:56Z or its Unix epoch) in your database, JSON payloads, and logs — it is unambiguous, sortable, and time-zone-aware. Convert to the user's preferred local format (US, EU, locale-specific) only at the rendering layer. This converter is built for exactly that round-trip: parse anything in, emit anything out, but never lose the canonical UTC anchor in the middle.

Related date utilities

Validate, compute, and translate datetimes with the rest of OpenFormatter's DateTime toolkit — all browser-side.

Frequently Asked Questions

Why are date formats so different across countries?

There is no global agreement on date order. The US writes month first (04/30/2026), most of Europe writes day first (30/04/2026), East Asia and ISO 8601 write year first (2026-04-30). The differences predate computing — they map to how dates were spoken aloud in each region. The fix for software is to pick one canonical form for storage (ISO 8601) and convert to local format only at the user-facing edge.

How do I prevent ambiguous dates like 1/2/2026?

A string like 1/2/2026 means January 2 in the US and February 1 in the UK — there is no way to know without context. Three rules avoid the trap: (1) always store dates as ISO 8601 (2026-01-02 or 2026-02-01); (2) on UI input, show the format hint next to the field (MM/DD/YYYY or use a date picker); (3) on parsing, require an explicit format and reject ambiguous strings rather than guessing. This converter lets you pick the source format precisely so you never guess.

Is YYYY-MM-DD ISO 8601?

Yes — YYYY-MM-DD is the calendar-date form of ISO 8601 (extended format). Adding a time component makes it the full datetime: YYYY-MM-DDTHH:MM:SS. The standard explicitly mandates four-digit year, two-digit month, and two-digit day with hyphen separators, so 2026-04-30 is canonically valid; 2026-4-30 is not.

Can I round-trip US format to EU and back?

For unambiguous dates (day > 12), yes — 04/30/2026 (US) maps cleanly to 30/04/2026 (EU) and back. For ambiguous dates (both fields ≤ 12), it depends on which field you treat as month. The safe round-trip is US → ISO 8601 → EU; storing the canonical form between conversions removes all ambiguity. This tool does exactly that internally.

What date format do databases use?

PostgreSQL, MySQL, SQL Server, and Oracle all natively store TIMESTAMP and DATE in canonical UTC form internally and accept ISO 8601 (YYYY-MM-DD HH:MM:SS) as the standard input. SQLite stores them as ISO 8601 strings or Unix epoch integers. The "SQL format" output of this tool emits the YYYY-MM-DD HH:MM:SS form which all major databases accept without configuration.

Should APIs use ISO 8601?

Yes. JSON has no native date type, so dates travel as strings — and ISO 8601 (specifically the RFC 3339 subset) is the universal convention. JSON.stringify(new Date()) emits it, OpenAPI specifies it for the format: date-time keyword, GraphQL DateTime scalars use it, and every JSON client library parses it. Using anything else (Unix timestamps, MM/DD strings, custom formats) means every consumer must code for your specific format.

Why is RFC 2822 used in email?

RFC 2822 (the email message format, descended from RFC 822 / 1982) predates ISO 8601 in widespread internet use. Its date format — Tue, 30 Apr 2024 08:40:34 GMT — is mandatory in the Date: header of every email message. It survives because every SMTP server, every email client, and every spam filter parses it. JavaScript Date.toUTCString() emits this form for compatibility.

How do I handle dates without a time component?

A pure date (2026-04-30) represents a calendar day, not a moment in time. The trap is that JavaScript new Date("2026-04-30") interprets it as midnight UTC, which can shift to the previous day in negative-offset timezones. Three options: (1) store as a string and never coerce to Date; (2) store with explicit noon UTC (2026-04-30T12:00:00Z) to keep the calendar day in any timezone; (3) use a date-only library like Temporal.PlainDate (when available) or date-fns lightFormat.

Date Format Converter — Convert 20+ Date Formats