Also available in: Español · Português · Français · العربية
ISO 8601 Parser and Validator
Paste any ISO 8601 string and see what it means, which grammars accept it, and what your own browser makes of it.
What is the ISO 8601 format?
ISO 8601 is the international standard for writing dates and times so that they sort correctly, read the same in every country, and never leave anyone wondering whether 03/08 means March or August. Its best-known spelling is the one most people mean by “the ISO 8601 format” — a date as 2026-08-03, a time appended after a T, and an offset from UTC on the end, giving 2026-08-03T12:00:00Z.
The standard is considerably larger than that one spelling, and this is where most confusion starts. ISO 8601 also defines dates written without separators, dates that give the day of the year instead of the month, dates that number the week rather than the day, durations, and intervals between two points. All of them are ISO 8601. Very little software accepts all of them.
So a validator that answers only “valid” or “invalid” is answering a question that has no single answer. This one gives three verdicts side by side — ISO 8601, RFC 3339 and the format JavaScript defines — because a string can be perfectly good by one and rejected by the other two, and knowing which is what actually helps.
How to use the parser
- Paste your string. A date, a date and time, a duration beginning with P, or an interval with a slash in the middle. The sample buttons load one of each, including two that most parsers refuse.
- Read what it means. The resolved date, the instant in UTC and in your own time zone, the offset as written, and the same date expressed as an ordinal and a week date so you can see the other spellings of it.
- Check the three verdicts. Each grammar says whether it accepts the string and, when it does not, exactly which rule it broke. Underneath, your own browser has a go at the same string.
ISO 8601, RFC 3339 and JavaScript are three different sets
These three names get used interchangeably and they should not be. We measured all three against the same strings, and none of them is a subset of another — they overlap.
JavaScript's Date.parse takes 2026 and 2026-08, a lowercase t and z, a space where the T belongs, and an offset written +0200 without a colon. It refuses the basic form 20260803, the week date 2026-W31-1, the ordinal date 2026-215, and — this is the strange one — a fraction written with a comma, which is the separator ISO 8601's own grammar lists first. Python's standard library makes almost the opposite set of choices: it accepts basic notation, week dates and the comma, and refuses 2026-08, lowercase letters and the hour 24. An ordinal date is rejected by both, and it is perfectly legal ISO 8601.
RFC 3339, the profile used across internet protocols, is the strictest of the three and is a normative grammar rather than a description. It requires the T, requires the offset to be present and written in full as ±HH:MM, and allows only a full stop before a fractional second. It also permits something neither of the others will touch: a leap second, written as :60. So 2016-12-31T23:59:60Z is a valid RFC 3339 timestamp that essentially no date library can represent.
The specification JavaScript uses is honest about its own scope. ECMA-262 section 21.4.1.32 describes its format as “a simplification of the ISO 8601 calendar date extended format” — so week dates, ordinal dates and the basic notation are outside it by design, not by oversight. Anything that does not match is, in the specification's words, left to “any implementation-specific heuristics”, which is why the tool runs Date.parse in your browser rather than telling you what browsers do.
Date.parse is not a date validator
This is the trap worth knowing, and it is not a browser bug — it follows from the specification. The JavaScript format gives the day as “two decimal digits from 01 to 31”, with no reference to the month. So 2026-02-30 is a conforming string, and browsers parse it and then let the day overflow: you get 2 March. Meanwhile 2026-13-01 returns NaN, because 13 is outside the stated range for a month.
The upshot is that checking a date by asking whether Date.parse returns NaN accepts the 30th of February, the 31st of April and the 29th of February in a year that has no such day. This parser refuses all of them, which is why the sample buttons include one — paste it and the tool will tell you that your own browser accepted an impossible date, and show you which date it invented.
There is a second specified surprise in the same area. ECMA-262 section 21.4.3.2 states that when the offset is absent, date-only forms are read as UTC and date-time forms are read as local time. So 2026-08-03 is midnight UTC, while 2026-08-03T00:00:00 is midnight where you are — adding a time to a date silently moves the instant by your whole offset, and the same string means different moments on different machines. The tool flags this whenever your input has no offset.
The forms most tools have never seen
An ordinal date replaces the month and day with the day of the year: 2026-215 is the 215th day of 2026, which is 3 August. A week date numbers the week instead: 2026-W31-1 is the Monday of week 31. Week numbering has a rule that surprises people — a week belongs to whichever year contains its Thursday, so the first week of a year can begin in December. 2026-W01-1 is 29 December 2025, and the tool says so when the two years differ.
Basic notation simply drops the separators, giving 20260803 and 20260803T120000Z. It is the form you meet in file names, in older data exports and in the EXIF blocks inside photographs, and it is the reason a bare eight-digit number in a data file is so often a date.
A duration begins with P: P3Y6M4DT12H30M5S is three years, six months, four days, twelve hours, thirty minutes and five seconds. The tool will total one up in milliseconds — but only when it can. A duration using years or months has no fixed length, because how long it lasts depends on when it starts, so no honest single number exists and the tool says that rather than picking an average. An interval is two of these separated by a slash, in any of three combinations: two instants, an instant and a duration, or a duration and an instant.
What this page will not pretend to know
ISO 8601 is sold by the International Organization for Standardization and is not free to read. The grammar this tool checks against is the collected ABNF published as Appendix A of RFC 3339, which is the closest thing to a citable free version — and it disclaims itself in some detail. It is marked informational, it was assembled from the 1988 edition, and it opens by stating that ISO 8601 defines no formal grammar at all.
It then lists four places the standard is unclear: whether basic and extended notation may be mixed in one string, whether the hour 24 is allowed only when the minutes and seconds are zero, whether the T may ever be dropped, and a decimal-fraction rule where section 5.3.1.3 and Annex B.2 of the standard contradict each other outright. The RFC's authors had to decide which of the two was in error. That is the state of the art on a standard everybody cites as though it settled things.
The hour 24 is a good illustration of how little agreement there is. ECMA-262 permits it, and adds a note saying this is consistent with ISO 8601 “even though that specification reserves it for describing time intervals and does not permit it within representations of single points in time”. RFC 3339's appendix says instead that ISO 8601 is “not clear” on the question and assumes hour 24 is permissible anywhere. Two free documents describing the same paywalled standard, disagreeing about what it says.
Finally, the range. JavaScript dates cover roughly 273,790 years either side of 1970, and the last instant one can hold is 13 September 275760. Anything beyond that is refused here rather than shown wrong, because the specification says such strings must return NaN without falling back to guesswork.
Why is it free?
The parsing happens in your browser. Nothing you paste is uploaded, logged or stored — closing the tab is all the deletion there is. That matters more than usual here, because the timestamps people need to decode often come out of production logs and error reports.
No account, no sign-up, no limit on how many strings you check, and no watermark on anything you copy out.