Skip to content
OneKitly
Sign up · Sign in

The JSON Export Keeps Three Things the CSV Has No Column For

Published 9/9/2026 · 3 min read · File tools

Daniel Okonkwo

Daniel Okonkwo — Front-end developer and tech writer at OneKitly

Web performance · File formats

Checked against 3 sources

View profile →
In short

Both exports read the same .ics with the same parser, and then diverge on what they can carry. The CSV writes eight fixed columns — summary, start, end, location, description, organizer, status, uid — because a spreadsheet is a rectangle and every event has to fill the same one. The JSON writes each event as an object, so a field that only some events have simply appears on those. In practice that means three things survive the JSON and not the CSV: tzid, the named time zone a start was written in; allDay, the marker that says a date is a whole day rather than an instant; and rrule, the recurrence rule. A weekly meeting exported to JSON comes back with "rrule": "FREQ=WEEKLY;BYDAY=MO;COUNT=12" attached, and a Christmas entry with "allDay": true. Neither has anywhere to go in a table. Take the CSV to read and sort; take the JSON when a script, an import routine or another calendar is going to consume it.

Same file, same parser, two outputs. The spreadsheet gets eight columns; the JSON gets the named time zone, the all-day flag and the recurrence rule as well.

A rectangle against a shape

A CSV has to decide its columns before it writes its first row, and every row afterwards has exactly those. That is a strength when you want to sort by start date or count events per location — a spreadsheet does those things instantly and a nest of objects does not. It becomes a weakness the moment the data is irregular, and calendar data is irregular by nature: most events have no recurrence, a few do; most have a zone, all-day entries have none.

There is a second, smaller difference worth knowing when a script reads the output. In the CSV an empty field is an empty cell that is always there; in the JSON an optional field that has no value may be absent from the object altogether. Write your reader to treat a missing key and an empty string the same way and neither export will surprise you.

Two events, both exports, side by side
PropertyIn the CSVIn the JSON
Title, start, end, uidYes, four of the eight columnsYes
Named time zoneNo column"tzid": "Europe/Paris"
Whole day rather than an instantNo column"allDay": true
Recurrence ruleNo column"rrule": "FREQ=WEEKLY;BYDAY=MO;COUNT=12"
An empty fieldAn empty cell, always presentAn empty string, or the key is absent
ICS to JSONExport calendar events as JSON, with each ICS timestamp converted to ISO-8601.Try the tool →

Frequently asked questions

Can I turn the JSON back into a calendar?
Not directly here — the import side takes CSV — but the JSON is the right thing to feed a script that writes .ics itself, precisely because it still holds the zone, the all-day flag and the rule. If all you need is to move a calendar unchanged, do not go through either export: merging .ics files keeps everything and skips the question.
Does the JSON expand the recurring events?
No, and it should not: it carries the rule instead, which is strictly more information. One object with an rrule of FREQ=WEEKLY;COUNT=12 tells you both that there are twelve occurrences and how they are spaced, while twelve expanded objects would tell you the dates and lose the fact that they belong together. Expanding is a job for whatever consumes the file.
Which one should I archive?
The .ics itself. Both exports are readings of it, and a reading always drops something — the JSON drops attendees, alarms and attachments just as the CSV drops the zone and the rule. Keep the original as the record and generate whichever export you need from it when you need it.

Articles you may find interesting

All guides →
ExplainerA Recurring Event Is One Line in the CSV, Not TwelveAn .ics file stores a weekly meeting once, with a rule attached. Export it to CSV and you get a single row for the whole series — which is the file being honest, not the converter losing rows.ExplainerThe Same .ics File Can Mean Five Different TimesiCalendar writes a start time in one of three ways, and only one of them is unambiguous. A meeting written with a named zone, converted on machines in Paris, New York and Honolulu, spanned nineteen hours and changed day.How-toBuilding a Calendar From a Schedule You Already Have in a SpreadsheetCourse timetables, match fixtures, shift rotas and conference programmes all start life as a table. Four columns are enough to turn one into a file every calendar application can import.ComparisonTwo Emails in One Cell, or Two Strings in an ArrayA contact can have several phone numbers and several addresses. The CSV joins them with a middle dot into one cell; the JSON keeps them as a list, which is the difference between a script that works and one that splits on a guess.How-toMerging Calendars and Address Books Appends — It Does Not DeduplicateThe merge tools put every record from every file into one output, in the order you gave them. That is the right default and the one thing to know before you feed in two exports of the same account.ExplainerA vCard Address Has Seven Parts, and a CSV Column Has OneNames, addresses and organisations are structured fields in a vCard. Flatten them into a spreadsheet and they read identically while losing the seams — which matters the moment you build a vCard back out of that spreadsheet.

Related tools

ICS to JSONExport calendar events as JSON, with each ICS timestamp converted to ISO-8601.ICS to CSVTurn a calendar file into a spreadsheet of events, with real dates instead of ICS stamps.ICS viewerOpen a calendar invitation or export and read its events before importing anything.VCF to JSONExport a vCard address book as structured JSON, with emails and phones as arrays.

Sources

Spotted a mistake in this article?