ICS File Validator — Check a Calendar File for Errors
Drop an .ics file into this ICS file validator. This is a lint, not a certification: it checks VCALENDAR/VERSION wrappers, DTSTART presence, date/time syntax (including impossible dates), DTEND ≥ DTSTART, UID/DTSTAMP presence, TZID references, conflicting VTIMEZONE, 75-octet folding on raw lines, RRULE basics and unclosed components. 100% in your browser — the file is never uploaded.
Drop an .ics file here
or click to browse. The file stays in your browser — nothing is uploaded.
What the validator checks
The lint is split into errors, warnings and an info summary. Errors mean the file is likely to break on import. Warnings mean it works in most apps but is out of spec on a point we check. This is not a certification. Info tells you what is in the file.
| Check | Level | Why it matters |
|---|---|---|
| BEGIN:VCALENDAR + END | Error | Without the wrapper, no app recognizes the file as a calendar |
| VERSION:2.0 | Error | The only current iCalendar version |
| DTSTART present | Error | An event without a start date cannot be placed on a calendar |
| DTEND ≥ DTSTART | Error | An event that ends before it starts is rejected by strict parsers |
| Valid date format | Error | Dates must be YYYYMMDD or YYYYMMDDTHHmmss[Z]; impossible dates (e.g. 30 Feb) fail |
| UID present | Warning | Required for update detection and duplicate prevention |
| Unique UIDs | Warning | Duplicate UIDs make events overwrite each other on import |
| DTSTAMP present | Warning | Used by apps for conflict resolution |
| VTIMEZONE defined | Warning | Events referencing an undefined TZID may default to UTC |
| Conflicting VTIMEZONE | Error | Same TZID with different bodies; identical repeats are a warning |
| RRULE basics | Error | FREQ required; COUNT and UNTIL must not both be set; unknown parts warn |
| Unclosed components | Error | A truncated VEVENT or missing END:VCALENDAR is malformed |
| Line folding (75 octets, raw lines) | Warning | Measured before unfolding; folded continuations are not flagged |
| CRLF line endings | Warning | Spec requires \\r\\n; bare \\n is tolerated but technically wrong |
When to validate an ICS file
- Before distributing a calendar invite. If you generated an .ics from a spreadsheet, a script or an online tool (including this site), run it through the validator before you send it out. One bad date format or a missing UID can silently create a duplicate in every recipient’s calendar.
- After merging multiple .ics files. Merged files often have duplicate UIDs, conflicting VTIMEZONE blocks or truncated events. The validator catches all three. If you need to combine files, the ICS merger on this site handles deduplication automatically.
- When an import fails or looks wrong. “Why did Google Calendar put this event on the wrong day?” is usually a date format or timezone issue. The validator shows you exactly what the file contains so you can compare it to what the app displayed.
- Debugging a calendar feed or script output. If your code generates ICS programmatically, running the output through a validator is cheaper than discovering the bug in production when someone’s meeting disappears.
Validator vs editor vs viewer — which one?
- Check the file — this page. Find out whether the file is valid before you send or import it. No changes are made.
- Fix the file — the ICS editor. Change titles, dates, times and locations, then download a corrected version.
- Read the file — the ICS viewer. See what events are in the file without importing anything.
ICS validator — frequently asked questions
What does the ICS validator check?
It is a lint, not a certification. It checks VCALENDAR/VERSION wrappers, DTSTART presence, date/time syntax (including impossible dates), DTEND ≥ DTSTART, UID/DTSTAMP presence, TZID references, conflicting VTIMEZONE, 75-octet folding on raw lines, RRULE basics (FREQ required; COUNT and UNTIL exclusive), unclosed components, duplicate UIDs and CRLF vs LF line endings. Errors mean the file will likely break on import; warnings mean most apps still accept it.
Does the validator upload my file?
No. The file is read and checked entirely in your browser. It is not uploaded, stored on a server, or sent anywhere. That is the same privacy model as every other tool on this site.
What is RFC 5545?
RFC 5545 is the Internet standard that defines the iCalendar format — the .ics files used by Google Calendar, Apple Calendar, Outlook and every other calendar app. It specifies which properties are required, how dates and times are encoded, how timezones are declared, and how lines are folded. This page runs a lint of the subset listed above — it is not a full RFC 5545 certification.
The validator found errors — how do I fix them?
For date, title and timezone issues, use the ICS editor on this site: drop the file, fix the fields the validator flagged, and download a corrected version. For structural problems (missing VCALENDAR wrapper, truncated file), the file may need to be re-exported from the calendar app that created it.
Why does my file have warnings but still imports fine?
Calendar apps are forgiving. Google Calendar, Apple Calendar and Outlook all tolerate missing UIDs, bare LF line endings, unfolded lines and other spec violations. The warnings tell you where the file deviates from the standard — they matter when the file needs to work across many different apps or when a strict parser is in the chain.
Can I validate a file exported from Google Calendar or Outlook?
Yes. Drop any .ics file regardless of where it came from. Exports from Google Calendar and Outlook are generally well-formed, but edge cases exist — especially with recurring events, timezone encoding and all-day event boundaries.