CSV to ICS Calendar Converter

The youth league publishes the season as a spreadsheet: forty games, six fields, dates typed by a volunteer at 11 p.m. Every family wants those games in their phone calendars, and nobody is going to type forty events by hand. The bridge between the spreadsheet and every calendar app on earth is a small, ancient, beautifully specified file format called iCalendar — .ics — and this converter builds it from your CSV.

The .ics format is one of the quiet success stories of the internet: specified in RFC 5545, it has been imported by Google Calendar, Outlook, and Apple Calendar for the better part of two decades. Anything that can produce a valid .ics file can populate anyone's calendar. That is why exports from booking systems, universities, sports leagues and conference platforms all eventually hand you one — and why being able to build one from a spreadsheet is a minor superpower.

The hard parts are not what people expect. The syntax is easy; the semantics are where schedules break — all-day events whose end dates are exclusive, timezones that shift under daylight saving, lines that must fold at 75 octets, and commas that must be escaped inside summaries. This converter handles the specification correctly and tells you what it decided along the way, and this article documents the rules so you can verify that behavior yourself.

Everything runs locally in your browser. A schedule with staff names, home addresses and appointment details is exactly the kind of file that should not be uploaded to a converter service, so it never is.

The converter is above this text. The flow, using a typical schedule export:

1. 1

   Paste or load the CSV

   Delimiter detection handles commas, semicolons and tabs; the header row becomes the column list you will map from. The preview shows parsed rows so malformed dates surface before conversion, not after import.

2. 2

   Map your columns

   Point the converter at your title, start, end, description and location columns. Every schedule names these differently — Subject/Event Name/What — and the mapper does not care. Optional mappings: UID from an ID column, reminders, categories, recurrence.

3. 3

   Set the timezone handling

   Choose a named IANA timezone for timed events, UTC, or floating times. All-day events ignore timezones by definition — they are dates, not moments — and the tool treats them accordingly.

4. 4

   Review the interpretation report

   Row counts, events with missing ends (duration applied), date-format detection results, and any rows that failed to parse. You will know exactly what the calendar file contains before you download it.

5. 5

   Download the .ics

   One file, RFC 5545-valid: CRLF line endings, folded lines, escaped punctuation, required properties on every event. Re-importing updates events via stable UIDs rather than duplicating them.

6. 6

   Import into your calendar

   Google Calendar: Settings → Import & Export, pick the file, choose the target calendar. Outlook and Apple Calendar open it directly. Import into a test calendar first if the schedule is high-stakes — it takes ten seconds and eliminates the one bad import that ruins a morning.

The whole trip takes about a minute. The verification habit at the end is the part worth keeping: import into a scratch calendar, glance at the week view, then import to the real one.

An .ics file is a stream of lines with the shape PROPERTY:VALUE. The outer wrapper is a VCALENDAR that must carry VERSION:2.0 and a PRODID — the identifier of whatever produced the file. Inside it, each event is a VEVENT block, and each VEVENT must carry a UID (globally unique identifier) and a DTSTAMP (the moment the event record was created). Those four properties are the spec's non-negotiables; a file missing any of them fails strict validation, and while Google is forgiving, Outlook occasionally is not.

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Toolzep//CSV to ICS//EN
CALSCALE:GREGORIAN
METHOD:PUBLISH
BEGIN:VEVENT
UID:row-2@toolzep.local
DTSTAMP:20261025T120000Z
SUMMARY:Team Standup
DTSTART;TZID=America/Chicago:20261102T090000
DTEND;TZID=America/Chicago:20261102T091500
LOCATION:Conf Room B
DESCRIPTION:Daily sync
RRULE:FREQ=WEEKLY;BYDAY=MO
END:VEVENT
END:VCALENDAR

Read the date-time values closely, because they encode the timezone decision. 20261102T090000 with a TZID parameter means 9:00 a.m. in Chicago, Central Time, with daylight saving applied automatically by the importing calendar — a November date lands in standard time, a July date in daylight. 20261025T120000Z with the Z suffix means noon UTC, an absolute moment in time. A bare 20261102T090000 with no timezone at all is a floating time: it displays as 9:00 a.m. wherever the viewer happens to be. All three are legal; they mean different things; and choosing among them is the one decision a converter cannot make for you. All-day events are different again — DTSTART;VALUE=DATE:20261225 is a date with no time component, deliberately timezone-free.

Two mechanical rules complete the picture. Lines must not exceed 75 octets: longer content is folded by inserting CRLF followed by a single space, and the importing calendar unfolds and rejoins the text. And text values — SUMMARY, LOCATION, DESCRIPTION — escape their special characters with backslashes: a literal comma becomes \, (commas otherwise separate property parameters), a semicolon becomes \;, a backslash becomes \\, and a newline inside a description is written as the two characters \n. A converter that skips the escaping produces calendar entries with mysteriously truncated titles, which is the classic symptom of an unescaped comma in the summary.

A realistic mixed schedule: a recurring standup, a one-off evening event with a timezone, and a company holiday. Three rows, three different date-time shapes — exactly the mix that breaks naive converters.

The detail that trips most converters is visible in event 3: DTEND for all-day events is the day after the last covered day. The CSV said the holiday is on December 25; the calendar file says it ends on December 26. That is not an off-by-one bug — it is the specification's design, the same way a hotel checkout on the 26th means you slept there on the 25th. The converter translates between the human convention in your CSV (ends on the last day) and the file convention (ends exclusively), and the interpretation report states which rows were all-day so nothing is silent.

Event 2 quietly demonstrates why named timezones beat manual offsets. If the converter had emitted UTC with a fixed offset for Chicago, a March event would land an hour off after the daylight-saving switch. By emitting TZID:America/Chicago and letting the calendar do zone math, every event lands correctly year-round. That is the difference between storing a moment and storing an intent.

Timezone handling has exactly three defensible strategies, and the converter supports all three explicitly rather than picking silently. Named IANA timezones (TZID) are right for shared calendars whose events live in a physical place — offices, venues, fields. UTC is right when the source data is already absolute — server logs, flight departures already stored in UTC. Floating local time is right almost never, but it has one legitimate use: personal calendars that should follow the owner across timezones, like medication reminders. What is never right is guessing, which is why the timezone setting is a visible control with a default you can override.

A word on the zone names themselves: they are IANA database identifiers — America/Chicago, Europe/Berlin, Asia/Tokyo — not the abbreviations people type instinctively. CST is ambiguous (Central Standard Time in the US, China Standard Time, Cuba Standard Time); America/Chicago is not. The converter's picker offers the IANA names with search, because typing the right identifier from memory is a hobby nobody should need.

All-day events interact with timezones in the way that surprises people: they do not interact at all. An all-day event is a date on a calendar page, not a moment on the world's clock. December 25 is December 25 whether you view it from Tokyo or Toronto — which is precisely why VALUE=DATE exists as a separate form from DATE-TIME. The converter marks rows as all-day when the end date equals the start date (or is blank) and no time component exists, and the report lists them so you can confirm the interpretation matches your intent.

Schedules disagree about column names more than about anything else. The mapper accepts whatever you have and treats these as the canonical targets:

The recurrence mapping deserves one paragraph of honesty. RRULE is powerful — FREQ, INTERVAL, COUNT, UNTIL, BYDAY, BYMONTH, BYSETPOS compose into rules like second Tuesday of every month — and the friendly builder covers the common patterns. But spreadsheets also encode recurrence as data: forty rows, one per occurrence. That style converts trivially (every row is an event), and it is often the better choice anyway, because per-occurrence details — different fields, canceled weeks — cannot be expressed in a single recurring rule. Forty explicit rows beat one clever RRULE whenever the exceptions outnumber the pattern.

The failure modes of .ics generation are small, mechanical, and entirely avoidable — which makes encountering them in the wild extra annoying. Here is the field guide.

• The unescaped comma: a title like Board Meeting, Q4 review becomes Board Meeting with the rest silently dropped, because a comma inside an unquoted iCalendar text value is read as a parameter separator. The converter escapes commas, semicolons and backslashes in every text property. If you have seen mysteriously truncated calendar titles from other tools, this was almost always it.
• The unfolded line: a description longer than 75 octets is invalid unless folded with CRLF + space. Some tolerant importers accept long lines anyway; some drop them; Apple Calendar has historically been picky. Folding is boring and the converter does it.
• The double-quoted CSV date: Excel exports dates as 11/2/2026 sometimes wrapped in quotes with the locale of the exporting machine. The parser unwraps and interprets per the column-level format detection, and flags what it cannot prove.
• The missing DTEND: events with a start but no end are legal in iCalendar, but most viewers render them as zero-length. The converter applies a default duration (configurable, 60 minutes by default) and lists the affected events in the report.
• The duplicate UID: if your CSV's ID column has repeats — and roster exports love repeated IDs — calendars treat re-imports as updates, silently collapsing events. The report flags duplicate IDs before you find out the hard way.
• The BOM: a UTF-8 byte-order mark at the start of the CSV turns the first header into an invisible misparse if the reader is careless. Handled; mentioned here only because it breaks so many other tools that people blame the format.

The converter's regulars, in rough order of volume:

• Sports league coordinators pushing season schedules to dozens of families at once — the canonical use case, forty games, one file.
• School and university administrators turning term dates, exam schedules and holiday lists into subscribable calendars.
• HR and office managers publishing shift rosters, on-call rotations and company holidays to shared team calendars.
• Event organizers migrating conference sessions, workshop tracks and venue assignments out of planning spreadsheets.
• Trainers and studios converting class timetables for clients — recurring classes with occasional exceptions map cleanly.
• Volunteers of every variety, because volunteer organizations run on spreadsheets and always will.

The shared situation: the data already exists in rows, and the audience wants it in their calendar. Nobody in that position should be typing events by hand, and nobody needs a backend system to avoid it — a correctly generated .ics file is the entire bridge.

Search csv to ics and much of what surfaces is scripts: Apps Script snippets that read a Sheet and create calendar events programmatically. Those work, and for a schedule that lives permanently in Google Sheets with a script that re-syncs on edit, the scripted approach is genuinely better. The honest comparison:

One more advantage worth naming: the .ics file is calendar-agnostic. The same file imports into Google, Outlook and Apple calendars, and can be emailed to a distribution list where every recipient imports it themselves. Scripted solutions typically create events in one specific calendar — fine when your whole organization is on one platform, limiting the moment it is not.

Schedules leak personal information constantly: home addresses in location fields, medical appointments in titles, staffing rotas that name who is vulnerable when. Uploading that to a conversion service to get a calendar file back is a bad trade, and this tool never asks for it. The CSV is parsed in your browser, the timezone arithmetic is local date math, and the .ics file is assembled in memory and downloaded directly. No server sees the schedule, which also means no server can lose it.

The local design has a practical bonus for the recurring user: it works offline. Coordinators running registrations at a field with terrible reception can still convert the day's schedule from a laptop, because the page needs no network once loaded.

The questions that arrive from people mid-migration.

The natural companions: the CSV to JSON Converter for schedules heading into APIs instead of calendars, the Date Difference Calculator for sanity-checking event durations before you commit them to a file, and the Time Zone Converter for resolving the multi-city questions a schedule with named timezones inevitably raises.