Why pull events out of an .ics file?
You exported your calendar, opened the file, and got a wall of BEGIN:VEVENT blocks. Useless for anything practical. ICS is a transport format meant for calendar apps to talk to each other, not for a human to read or for a spreadsheet to import.
Paste that file here and you get a tidy table back. Each event becomes one row with six columns: Summary, Start, End, Location, Description, and Organizer. From there you can drop it into Excel, Google Sheets, a database import, or a quick pivot to count how many meetings ate your week.
How the parser reads the file
ICS has a few quirks that trip up naive splitting, so the parser handles them before anything else.
Folded lines get stitched back together. RFC 5545 says any line longer than 75 characters wraps onto the next line with a leading space or tab. A long description can spread across three or four physical lines. The parser detects those continuation lines and joins them first, so nothing gets cut mid-word.
Escaped characters get decoded. Inside ICS values, commas and semicolons are escaped as \, and \;, newlines show up as \n, and a literal backslash is \\. Those all get turned back into the real characters. So Sprint planning\, Q3 roadmap comes out as Sprint planning, Q3 roadmap.
Dates get made readable. A DTSTART can be a plain date like 20260704 or a full timestamp like 20260622T140000Z. The first becomes 2026-07-04. The second becomes 2026-06-22 14:00:00 UTC. The trailing Z flags UTC, and it’s labeled as such instead of silently dropped.
Organizer names come through clean. The ORGANIZER field is usually a mailto: URI, sometimes with a CN= parameter holding the person’s name. When the name is there, you get Dana Wu <[email protected]>. When it isn’t, you just get the email.
A note on the CSV it produces
The output follows RFC 4180. Any field containing a comma, a quote, or a line break gets wrapped in double quotes, and quotes inside the field are doubled. That’s what keeps a multi-line description from blowing apart your columns when you open the file in a spreadsheet. Rows are separated with CRLF, which is what Excel expects.
Hit Download and you get a calendar.csv ready to open. Or copy the text and paste it straight into a sheet.
Good to know
Only VEVENT blocks are read. If your file has VTODO tasks or VJOURNAL entries, those are skipped, since they don’t map to the same six columns. Recurrence rules (RRULE) aren’t expanded either, so a weekly standup shows up as a single row, not 52. You get the rule’s base event, not every occurrence.
Timezone IDs like DTSTART;TZID=America/New_York keep their raw local time. The parser doesn’t shift them to UTC, because doing that correctly needs the full IANA timezone database. The number you see is the number in the file.
Everything happens locally in your browser. The file’s contents never leave your machine, which matters since calendar exports tend to carry names, email addresses, and meeting notes you’d rather not upload anywhere.
FAQ
Does it handle multi-day or all-day events?
Yep. All-day events use the date-only form (20260704) and show up as 2026-07-04 with no time. Multi-day events just have a Start and End on different dates.
What if an event has no location or organizer?
That cell is left blank. Missing fields don’t break the row or shift your columns, they just come through empty.
Will it expand repeating events into separate rows?
Nope. A recurring event appears once, as defined in the file. Expanding RRULE into individual dates isn’t supported here.
Can I convert just a single event?
Sure. Paste one BEGIN:VEVENT … END:VEVENT block on its own and you’ll get a header row plus one data row.
Why are some descriptions wrapped in quotes?
That’s correct CSV behavior. Any value holding a comma or a newline gets quoted so spreadsheet apps read it as one field instead of splitting it.