ISO 8601 Date Validator Online — Free RFC 3339 Checker

Validate ISO 8601 / RFC 3339 date strings in bulk. Catches malformed format, illegal leap days, out-of-range time components, and missing offsets — with a one-line explanation per error. 100% browser.

0 dates · 0 valid

ISO 8601 dates (one per line)

Validation results

Paste ISO 8601 dates above to validate them.

What is an ISO 8601 Validator?

An ISO 8601 validator checks whether a date string conforms to the international datetime format (and its stricter internet sibling, RFC 3339). It catches the silent bugs — wrong separators, missing offsets, illegal leap days, out-of-range hours — that crash JSON parsers, OpenAPI codegen, and SQL TIMESTAMP inserts when they hit production.

The OpenFormatter validator combines a strict regex against the spec pattern with semantic checks (leap-year rules, day-of-month limits, hour/minute/second ranges) and JavaScript's native new Date() parser. Bulk mode lets you paste an entire CSV column, and each line gets its own verdict and human-readable reason.

How to validate an ISO 8601 date online — 4 steps

Paste dates. Drop one date per line into the input area. Mix valid and invalid samples — the tool handles bulk input.
Read each verdict. Every line gets a Valid or Invalid badge with a one-line reason for failure.
Inspect parsed components. Valid rows expand to show year, month, day, hour, minute, second, ms, and offset.
Copy the canonical form. Each valid date emits its UTC canonical representation — the safest form to store and transmit.

Sample input and output

2026-04-30T12:34:56Z              ✓ Valid    canonical: 2026-04-30T12:34:56.000Z
2026-04-30T12:34:56.789+05:30     ✓ Valid    offset: +05:30  ms: 789
2026-02-29T00:00:00Z              ✓ Valid    leap year confirmed
2025-02-29T00:00:00Z              ✗ Invalid  Day 29 is invalid for 2025-02 (max 28, 2025 is not a leap year)
2026-13-01                        ✗ Invalid  Month 13 is out of range (1–12)
2026-W18-5                        ✗ Invalid  Week date — spec valid but JS Date cannot parse it
2026/04/30                        ✗ Invalid  Does not match ISO 8601 / RFC 3339 pattern

Strict Spec Validation

Combines a regex against the ISO 8601 / RFC 3339 pattern with semantic checks for leap years, day-of-month limits, and hour/minute/second ranges.

Human-Readable Errors

No "invalid date" — every failure tells you the exact problem (Day 29 invalid for 2025-02; Month 13 out of range; missing offset).

Bulk Mode

Paste an entire CSV column or log-extract; the validator processes every line and shows pass/fail at a glance.

Common use cases

check_circleValidating user-submitted dates before they hit your API or database
check_circleAuditing timestamps in JSON or NDJSON logs for spec compliance
check_circleCleaning a CSV column of mixed date formats before ETL
check_circleConfirming OpenAPI / Swagger date-time fields parse correctly
check_circleSpotting bad rows in a database dump before re-importing
check_circlePre-flight checking webhook payload timestamps from third parties
check_circleVerifying birthdate or transaction-date fields in user uploads
check_circleCatching DST and offset bugs in time-zone-aware data

Why ISO 8601 vs RFC 3339?

ISO 8601 is the broad standard (1988, last revised 2019); RFC 3339 (2002) is a profile of it written specifically for internet protocols. RFC 3339 forbids the rarer ISO forms — week dates (2026-W18-5), ordinal dates (2026-121), basic format without separators (20260430T123456Z) — and requires an explicit offset (Z or ±hh:mm) on every datetime. Picking RFC 3339 means picking the form that JSON, OpenAPI, GraphQL, JWT, RFC 5322 email, Atom, RSS, and almost every modern protocol agree on. When a spec says "ISO 8601" it almost always means "the RFC 3339 subset." This validator enforces the RFC 3339 form by default but also surfaces the spec-valid-but-unparseable ISO oddities so you know to convert them.

Need to convert, format, or compare?

Pair the validator with the rest of OpenFormatter's DateTime toolkit — every tool runs in your browser.

Unix Timestamp Converter Date Format Converter Time Zone Converter

Frequently Asked Questions

What is ISO 8601?

ISO 8601 is the international standard for representing dates and times as strings. Its core form is YYYY-MM-DDTHH:MM:SS±hh:mm — for example 2026-04-30T12:34:56Z. The standard was first published in 1988 and is now the default datetime format for JSON APIs, OpenAPI, GraphQL Scalars, SQL TIMESTAMP types, JavaScript JSON.stringify, and almost every modern protocol.

Is RFC 3339 the same as ISO 8601?

RFC 3339 is a strict subset of ISO 8601 designed for the internet. It mandates the four-digit year, hyphen-separated date, the literal T separator (or a space), seconds precision, and an explicit Z or ±hh:mm offset. ISO 8601 also permits forms RFC 3339 forbids: week dates (2026-W18-5), ordinal dates (2026-121), basic format without separators (20260430T123456Z), and reduced precision. When a spec says "ISO 8601" they almost always mean the RFC 3339 subset.

Are week dates and ordinal dates supported?

They are valid in the ISO 8601 spec — 2026-W18-5 (Friday of week 18) and 2026-121 (the 121st day) — but the JavaScript Date constructor and most JSON libraries do not parse them. This validator flags both forms with a note explaining they are spec-valid but parser-incompatible. If you need round-trip support, convert them to the calendar form (YYYY-MM-DD) first.

How are timezones represented in ISO 8601?

Three forms are valid. Z (uppercase) means UTC. +hh:mm or -hh:mm gives the offset from UTC (e.g. +05:30 for India, -05:00 for US Eastern Standard). The basic form ±hhmm without a colon is allowed by ISO 8601 but RFC 3339 requires the colon. A datetime without any offset is a "local" time — RFC 3339 forbids this; pure ISO 8601 allows it but it is ambiguous and usually a bug.

Why does my date string fail?

The most common causes: slashes instead of hyphens (2026/04/30), single-digit month or day (2026-4-3), missing zero padding in the time (12:34:5), missing offset on a datetime (2026-04-30T12:34:56), an invalid month (2026-13-01), or an impossible day (2025-02-29 is not a leap year). The validator returns an exact reason for each failure so you can fix it without guessing.

What is the most strict ISO 8601 format?

The strictest internet-safe form is RFC 3339 with extended format and UTC: YYYY-MM-DDTHH:MM:SSZ — e.g. 2026-04-30T12:34:56Z. Add fractional seconds for sub-second precision: 2026-04-30T12:34:56.789Z. This is what JSON.stringify(new Date()) emits, what JWT recommends for iat/exp claims expressed as strings, and what every well-designed API should send.

How does fractional seconds precision work?

ISO 8601 allows any number of digits after the decimal point on the seconds component — 2026-04-30T12:34:56.123 (ms), .123456 (μs), .123456789 (ns). RFC 3339 Section 5.3 allows arbitrary precision but recommends ms or μs for portability. The JavaScript Date object truncates after the third digit — anything beyond is silently dropped. This validator preserves the original string but reports parsed values to ms precision.

Are leap seconds supported?

ISO 8601 and RFC 3339 both allow second values of 60 to represent an inserted leap second (e.g. 2016-12-31T23:59:60Z). In practice, no major programming language Date type stores 60 — they coerce to 00 of the next minute or simply reject the input. This validator accepts second=60 as syntactically valid but warns that downstream parsers will likely reject it. Most production systems handle leap seconds via NTP smearing rather than a literal 60th second.