Validate ISO 8601 Online

How to Validate an ISO 8601 Date String Online

1. Paste Your ISO 8601 String: Drop a candidate date/time into the input box — anything from a bare date like 2026-05-26, a date-time 2026-05-26T14:30:00, a UTC instant 2026-05-26T14:30:00Z, an offset 2026-05-26T14:30:00+05:30, a week date 2026-W22-2, an ordinal 2026-146, or a duration P3Y6M4DT12H30M5S. Parsing happens in your browser session — nothing is uploaded.
2. Click Validate: The parser checks the string against ISO 8601-1:2019 grammar AND against the Gregorian calendar — so 2026-13-45 is rejected as a bad month and day, 2026-02-29 is rejected because 2026 is not a leap year, and 2026-W54-1 is rejected because 2026 has only 53 ISO weeks at most (and actually only 53 starts on a Thursday or a leap-year Wednesday).
3. Read the Result: A green "Valid" banner shows the parsed components — year, month, day, hour, minute, second, fractional seconds, time-zone offset — and the equivalent UTC instant for any zoned input. A red "Invalid" banner names the failure: bad month, day overflow for the month, invalid leap-day, malformed offset, missing T separator, or unrecognized form.
4. Fix and Re-Validate: Edit the input, click Validate again, and iterate until the banner turns green. Once valid, you can convert it to a Unix timestamp with Date to Timestamp, or go the other direction with Timestamp to Date.

Why Validate ISO 8601?

ISO 8601 is the international standard for date and time exchange (current revision: ISO 8601-1:2019, published 25 February 2019). It is the lingua franca of APIs, logs, file names, database columns, scientific data, and configuration formats — but the standard is wide. It allows basic compact forms (20260526T143000Z), extended hyphenated forms (2026-05-26T14:30:00Z), week dates, ordinal dates, durations, intervals, and two decimal separators (dot or comma). A string that looks correct can still fail the calendar (Feb 30 doesn't exist; 2026 has no Feb 29) or fail a stricter consumer like RFC 3339. Validate before you commit it to a record.

• Debug APIs that return 400 Invalid date format — Most JSON APIs require RFC 3339 (a strict subset of ISO 8601). If you sent 2026/05/26 14:30 or 2026-05-26 14:30+05:30 (space instead of T) the server will reject it. Paste the value here and the parser names the violation in plain English.
• Verify timestamps in JSON, YAML, TOML, and XML configs — Many parsers happily accept syntactically wrong but calendar-impossible dates like 2026-02-31. Spotting them at edit time saves a runtime exception later. Combine with Validate JSON or Validate YAML to check structure and dates in one pass.
• Confirm log timestamps before parsing — Centralized log pipelines (Elasticsearch, Datadog, Splunk, OpenSearch) reject malformed @timestamp fields and either drop the event or fall back to ingest time. A quick validation catches a busted strftime template before it corrupts a whole index.
• Pre-flight database inserts — PostgreSQL's timestamptz, MySQL's DATETIME, SQL Server's datetime2, and SQLite (via the date() function) all parse ISO 8601 strings, but they reject calendar-impossible values with cryptic SQLSTATE codes. Validate first; insert second.
• Sanity-check generated <time datetime="..."> attributes — HTML's <time> element accepts ISO 8601 datetime values. Browsers and crawlers (Google's structured-data parser in particular) will ignore the field silently if it's malformed, so an article's "published" date never makes it into the rich result.
• Confirm calendar arithmetic in code review — A function that emits 2024-12-30 for the last week of 2024 isn't necessarily wrong: in ISO week dates that week is 2025-W01, because week 01 always contains the first Thursday (equivalently, January 4) of the new year.

Working with related time formats? Try Date to Timestamp, Timestamp to Date, or build a schedule expression with the Cron Generator.

Valid ISO 8601 Forms — Quick Reference

Form	Example	Notes
Calendar date (extended)	2026-05-26	Most common; preferred by ISO 8601-1:2019 for human-readable text
Calendar date (basic)	20260526	Compact form; valid but the 2019 revision says "should be avoided in plain text"
Date + time, no zone	2026-05-26T14:30:00	Local time; ambiguous without context
Date + time, UTC	2026-05-26T14:30:00Z	Z is the zone designator for the zero UTC offset
Date + time, offset	2026-05-26T14:30:00+05:30	Offset from UTC (here, India Standard Time)
Fractional seconds	2026-05-26T14:30:00.123Z	ISO 8601 allows dot or comma; RFC 3339 requires dot
Week date	2026-W22-2	ISO year 2026, week 22, day 2 (Tuesday) — Mon=1, Sun=7
Ordinal date	2026-146	Day 146 of 2026 (= May 26) — useful in aviation, astronomy
Duration	P3Y6M4DT12H30M5S	3 years 6 months 4 days 12 hours 30 minutes 5 seconds
Interval	2026-01-01/2026-12-31	Start/end, or start/duration, or duration/end

ISO 8601 vs RFC 3339 vs Other Date Standards

Property	ISO 8601-1:2019	RFC 3339 (2002)	RFC 5322 (HTTP/email)
Scope	Full international standard	Internet protocol profile (subset of ISO 8601)	Internet message headers
Example	2026-05-26T14:30:00.123+05:30	2026-05-26T14:30:00.123+05:30	Tue, 26 May 2026 14:30:00 +0530
Date-time separator	T (or space by agreement)	T or a single space (lowercase t also tolerated)	Space-delimited fields
Week dates / ordinal dates	Yes	No — excluded from the profile	No
Durations / intervals	Yes	No	No
Basic format (no hyphens)	Yes (e.g., 20260526T143000Z)	No — punctuation is mandatory	N/A
Decimal separator	Dot or comma	Dot only	N/A
-00:00 offset	Forbidden (use +00:00 or Z)	Allowed, with the special meaning "UTC, local zone unknown"	N/A
Year range	0000-9999 (pre-1583 only by mutual agreement)	"Current era": 0000-9999 AD	Two- or four-digit years
Used by	Anywhere — files, logs, science, calendars	Most JSON / REST APIs, OpenAPI, OAuth, JWT iat/exp (as Unix), RFC 7807	HTTP Date and Last-Modified headers, email

Frequently Asked Questions

ISO 8601 vs RFC 3339 — which should my API use?

RFC 3339, almost always. RFC 3339 (published July 2002) defines a strict subset of ISO 8601 specifically for internet protocols, and it's the format you'll see in OpenAPI specs, GitHub's API, Stripe webhooks, Google Cloud, AWS, and most JSON APIs. The differences from full ISO 8601 are pragmatic: no week dates, no ordinal dates, no durations, mandatory hyphens and colons, dot-only decimal separator, and the special -00:00 offset for "UTC but local zone unknown" (which ISO 8601 forbids). If your audience is "everyone who consumes JSON," produce RFC 3339. If your audience is "humans reading a file" or "scientific data," the full ISO 8601 grammar (including week dates and durations) is fair game.

Does the validator check calendar validity, or just syntax?

Both. After parsing the grammar, the validator checks that the month is 1-12, the day is in range for that month (30/31 days, February 28 or 29), and the leap-year rule (divisible by 4, except centuries not divisible by 400) is honored. So 2026-13-01 is rejected as a bad month, 2026-04-31 is rejected because April has only 30 days, and 2026-02-29 is rejected because 2026 is not divisible by 4. Week dates and ordinal dates get the same treatment: 2026-W54-1 is rejected because 2026 has 53 weeks at most, and 2026-367 is rejected because 2026 is not a leap year (365 days).

Is Z the same as +00:00?

Functionally, yes — both denote a zero offset from UTC, and any compliant parser treats them as equivalent. Z is just shorthand. ISO 8601 explicitly defines Z as "the zone designator for the zero UTC offset." There is one nuance with RFC 3339 that catches people out: RFC 3339 also allows -00:00 and uses it as a sentinel for "the time is in UTC, but the local zone the event was generated in is not known." Full ISO 8601 forbids -00:00 outright — write +00:00 or Z instead.

Are fractional seconds supported? How many digits?

Yes. ISO 8601 allows any number of fractional-second digits and accepts either a dot (.123) or a comma (,123) as the decimal separator. RFC 3339 only allows the dot. In practice the precision your downstream consumer keeps depends on its time type: PostgreSQL timestamptz stores microseconds (6 digits), SQL Server datetime2(7) stores 100-nanosecond ticks, JavaScript's Date keeps milliseconds (3 digits) and silently truncates more, Java Instant and Python datetime keep nanoseconds and microseconds respectively. Write 3 digits and you're safe everywhere; write 9 and you may lose precision on round-trip.

Why is 20260526 valid but discouraged?

The basic (compact, no-hyphen) format is part of the standard — 20260526T143000Z parses cleanly per ISO 8601-1:2019. But the 2019 revision explicitly recommends against it for plain text: "the basic format should be avoided in plain text," because 20260526 is easy to mistake for an eight-digit integer, and 262605 (year-month-day or day-month-year in two-digit form?) is genuinely ambiguous. Use the extended form (2026-05-26) anywhere a human will read it; reserve basic form for fixed-width file names or barcode payloads where every character matters.

How do ISO week dates work? When does a year have 53 weeks?

Week 01 of an ISO year is the week containing the first Thursday of the Gregorian year — equivalently, the week containing January 4. Weeks run Monday (day 1) to Sunday (day 7). So 2026-W01-1 is Monday, December 29, 2025 (because January 1, 2026 is a Thursday and week 01 has to contain it). A year has 53 weeks when January 1 is a Thursday, or when it's a leap year starting on Wednesday — about 71 times per 400-year cycle (roughly every 5-6 years). 2026 has 53 weeks; 2027 has 52.

What's an ordinal date and where is it used?

YYYY-DDD — the day of year, 001 through 365 (or 366 in a leap year). 2026-146 is May 26, 2026. Ordinal dates show up in aviation (Julian-style day numbering on flight plans), satellite telemetry, NASA / ESA data products, ham-radio logs, and Unix's date +%j. They're rarely seen in business systems, but they're legal ISO 8601 and the validator will accept them.

Is ISO 8601 the same thing as a Unix timestamp?

No — completely different. ISO 8601 is a textual format for human-readable dates and times: 2026-05-26T14:30:00Z. A Unix timestamp is the integer count of seconds since 1970-01-01T00:00:00Z: 1779804600 for the same moment. ISO 8601 strings carry calendar structure (year/month/day) and a time zone; Unix timestamps are zone-less seconds. Most APIs that expose dates to humans use ISO 8601; most APIs that expose dates to other machines (JWT iat/exp, log files at scale, performance counters) use Unix timestamps. Convert between them with Date to Timestamp and Timestamp to Date.

Can I validate durations and intervals here?

Yes. ISO 8601 durations use the P (period) prefix: P1Y2M3DT4H5M6S is "1 year, 2 months, 3 days, 4 hours, 5 minutes, 6 seconds." Weeks are exclusive — write P3W for three weeks, but you cannot combine W with other components (P3W4D is invalid). Intervals use a / between two values: 2026-01-01T00:00:00Z/2026-12-31T23:59:59Z (start/end), or 2026-01-01T00:00:00Z/P1Y (start/duration), or P1Y/2027-01-01T00:00:00Z (duration/end). Durations and intervals are part of full ISO 8601 but excluded from RFC 3339.

Does the validator send my data anywhere?

No. Parsing runs in your browser via the page's JavaScript — no upload, no server call, no logging. You can validate timestamps from internal logs, audit trails, or anything else without it leaving your machine. Disconnect from the network after the page loads and validation still works.