How to read a calendar file without uploading it

Paste an .ics file into the box or pick one from disk — up to 5 MB, with the size shown next to the file name — and press Parse calendar. The calendar is read in the tab, so nothing is sent anywhere, and the JSON export works the same way. The summary names the calendar, its PRODID and version and counts the events, tasks and issues found; every entry appears below as a card with its date, location, RRULE text and description.

A file only has to be close to iCalendar to be useful here. Lines are unfolded first, so a continuation line starting with a space or tab joins the one above it; property names may be lower case; CN="Doe; John" keeps its semicolon inside the quoted parameter; and \, \; \n and \\ are decoded before a value is shown. A line the parser cannot split into a property and a value is reported with its number instead of stopping the whole file.

  1. Paste the calendar text or choose a local .ics file — the drop zone and the file field both load the text into the box.
  2. Press Parse calendar. Events and tasks are counted, drawn as cards and written into the result.
  3. Read the Issues row: missing UID, DTSTART or SUMMARY fields, a DTEND earlier than DTSTART, a date the viewer cannot read, an END without its BEGIN and lines it could not split are listed one by one, each named with its event, task or line number.
  4. Copy JSON or Download JSON to take the result out as calendar.json: the calendar properties, every event and task — nested components such as VALARM kept under components — the issue list and the number of lines read. Without a result both buttons say so.

What the parser checks, and where it stops

Dates, time zones and all-day entries

Four date shapes are read: 20260901T090000Z as UTC, 20260901T090000 as a floating local time, 20260901 as an all-day date, and a zoned value carrying a TZID parameter. The zone name is printed next to the value — DTSTART;TZID=America/New_York:20260901T090000 shows as 2026-09-01 09:00:00 (America/New_York) — and the clock time stays exactly as written, because the page has no time-zone database to convert it with. A value that fits none of those shapes is reported in the Issues row with its property name and raw text.

All-day entries print as dates. An event without DTSTART shows a dash where the date would be, and the issue list names the missing field.

Events, tasks and the JSON result

VEVENT and VTODO are kept apart: an event card carries its date range, location, RRULE text and description, a task card carries its due date. A property that appears more than once keeps every value (two ATTENDEE lines export an array), and nested components such as VALARM travel with their parent under components in the JSON.

RRULE is exported as text and not expanded: a weekly rule with COUNT=6 stays one event with the rule written out in full.

Where the checks stop

This is a reader with a short checklist, not a conformance test. It checks the fields named above and the shape of the file; it does not walk RFC 5545 property by property, it does not fetch a subscription URL, and it does not repair a damaged file. What it cannot read or split is named with the line number or the entry it came from, so a file that half-parses can be fixed exactly where it broke.

Recent tools: