How to import an iCal file into Google Calendar without creating duplicates

An .ics file arrives, or a calendar gets exported from an old account, and the next step looks obvious: open Google Calendar, import the file, done. It usually works. The trouble starts on the second attempt, when something looked wrong the first time and the file gets imported again, and now every event exists twice on a calendar that people rely on.

The import itself takes about a minute. The part worth planning is where the events land, because a calendar that received the wrong import can be deleted in one action, while events mixed into a primary calendar have to be removed one by one.

Import and subscribe are different jobs

Before importing anything, be clear about which of these is needed. Google's help pages treat them as separate operations, and choosing the wrong one is the most common reason people end up importing the same file repeatedly.

Goal	Operation	Result
Move events out of an old app or account, once	Import an .ics or .csv file	A copy of the events, frozen at the moment of export
Follow a calendar that someone else keeps updating	Add a calendar from a URL, or subscribe	A calendar that refreshes from its source

An import produces a snapshot. If the source keeps changing, that snapshot goes stale immediately, and the natural response is to import a newer file, which is exactly how duplicates appear. For a feed that is published at a webcal or https address, such as a holiday calendar or a sports fixture list, the right move is to add it by URL instead. Google's page on subscribing to a calendar covers that route, including the note that a calendar can only be added from a link when it is public.

The safe import, step by step

Google's import page describes the operation itself. The safety comes from two decisions made around it.

Step 1: create an empty calendar to receive the import

In the calendar list on the left, next to the heading for other calendars, use the option to create a new calendar. Give it a name that says what it is, such as Import test, and create it. This takes fifteen seconds and it is the single most useful habit in this whole process. If the import turns out wrong, deleting that calendar removes everything it brought with it, and nothing else is touched.

Step 2: import the file into that calendar

1. Open Google Calendar in a browser on a computer. Import is not available in the mobile apps.
2. At the top right, open Settings.
3. In the menu on the left, choose Import and export.
4. Choose the file from the computer. It must end in .ics or .csv.
5. Change the destination calendar from the default, which is the primary calendar, to the empty calendar created in step 1.
6. Click Import.

Google notes that a .zip file has to be unpacked first, and that each .ics inside it is imported individually. An export of several calendars usually arrives as exactly that, one file per calendar, which is another reason to import them one at a time into clearly named calendars.

Step 3: check three things before merging anything

Look at the imported calendar on its own, with other calendars hidden:

• Dates and times. Spot-check a morning event, an afternoon event, and one that falls in a different time zone or across a daylight saving change.
• All-day events. Confirm they sit on the right day rather than the day before or after.
• Recurring series. Open one and check that it is still a repeating event rather than a long row of separate entries.

Google's page warns about that last point for one specific case: repeat events imported from a .csv file may not stay repeating, and can appear as a series of one-time events. An .ics file carries the repeat rule properly, which is a good reason to prefer .ics when the exporting app offers a choice.

Step 4: decide what to do with the result

If the import looks right, there are two reasonable endings. Keep the events in their own calendar, which makes them easy to show, hide or color separately and leaves the primary calendar untouched. Or, if they truly belong in the primary calendar, move them there. Moving a large number of events one by one is slow, so for anything beyond a handful, the practical route is to delete the test calendar, then import the same file again with the primary calendar as the destination, now that the file is known to be correct.

What an import does not bring with it

Google states plainly that when an event is imported, guests and conference data for that event are not imported. That has consequences worth knowing before treating an import as a migration:

• Attendee lists disappear. Nobody is re-invited, which is good, but the record of who was coming is gone.
• Meeting links held as conference data do not survive. A Meet or Zoom link written into the description text usually does, since the description is plain text.
• Notifications and alerts follow the calendar's defaults rather than whatever the original event had, unless the file specifies them.

For a personal archive that is fine. For a live project calendar with recurring meetings and external guests, it means the imported copy is a record, not a working calendar. Recreating the key recurring meetings by hand is often less work than repairing an import.

Where duplicates actually come from

Google's help page does not document what happens when the same file is imported twice, so the practical assumption is that every import is additive. That points at four habits:

1. Never import the same file twice into the same calendar. If something needs retrying, delete the receiving calendar first and start again.
2. Import into an empty calendar. It converts a difficult cleanup into a one-click deletion.
3. Keep the exported files in one folder with the export date in the filename. Most double imports happen because two downloads with similar names were both tried.
4. Use a subscription for anything that keeps changing. Repeated imports of a moving calendar is the classic duplicate generator.

If duplicates already exist

Search is the fastest tool. Searching for the event title shows every copy across calendars, and the search result makes it clear which calendar each copy sits on. Where all the duplicates came from one import into a dedicated calendar, deleting that calendar clears them in one action. Where they were imported into the primary calendar, deletion is manual, and it is worth checking whether recreating the calendar from the original file is faster than removing hundreds of entries by hand.

Exporting a file that imports cleanly

The quality of the import depends on the file. A few points from the same Google page:

• From a different Google account, export produces a .zip containing one .ics per calendar. Unpack it and import the calendars separately.
• From other applications, choose .ics where possible. Google accepts .csv too, but .csv loses repeat rules.
• A .csv file must use English headers, and only Subject and Start Date are required. Getting an error on a .csv import usually means a header or a date format problem, not a Google fault.
• An .ics file has to begin with BEGIN:VCALENDAR and end with END:VCALENDAR, with each event between BEGIN:VEVENT and END:VEVENT. If a file was hand-edited and the import fails, that structure is the first thing to check.

Google also points out that events imported from another Google account do not stay in sync between the two accounts. If ongoing sync is the goal rather than a one-time move, sharing the calendar with the other account is the route that keeps it live.

When the import throws an error

An import that refuses to run is usually a file problem, and the message rarely says which line is at fault. Three checks resolve most cases.

Open the file in a text editor. An .ics is plain text. If the first line is not BEGIN:VCALENDAR, something wrapped it, and a mail client that saved the attachment as HTML is a common culprit. Re-download the attachment and save it without opening it in a browser.

Split a large file. A file holding years of events can fail as a whole while each half imports without complaint. Copy the header down to the line above the first BEGIN:VEVENT, paste it in front of the second half, add END:VCALENDAR at the bottom of each part, and import them separately. This also narrows down which event is malformed, because one half will fail and the other will not.

Check the character encoding and line endings. Files exported from old desktop applications sometimes carry characters that break the parse. Saving the file again as UTF-8 from a plain text editor clears that up without changing the events.

For .csv files the errors are different in kind. The headers must be in English, dates have to match the expected format, and any field containing a comma has to sit inside quotation marks. Building a small test file with two events and importing that first will show whether the format is right before a thousand rows go through.

On a Mac, the file is not always the answer

Plenty of imports start because an .ics arrived by email and the only way to read it seemed to be to put it somewhere permanent. A desktop calendar can help here in two ways. Overlaying a holiday or fixture feed from a webcal or ICS URL keeps that content out of the personal calendar entirely, and it stays current without anyone importing anything again. And where the .ics is really just an event inside a message, a calendar app for Mac that creates an event from pasted text can pull the date, place and meeting link out of that message directly, which is faster than saving a file and running an import for one appointment. The entering events section of the guide shows what that looks like in practice.

For a genuine migration out of an old calendar application, the file route remains the right one. It is just worth doing it once, into a calendar that can be thrown away.

One more habit pays off after the move. Keep the original export file somewhere durable, with the date in its name, even after the events are safely in Google. If a cleanup later removes the wrong calendar, that file is the only way back, and exports from an application that has since been uninstalled cannot be repeated. Storing it next to any other archive material, rather than leaving it in a downloads folder that gets cleared, costs nothing and removes the worst case entirely.

What to change first

Make an empty calendar, import into that, and only merge once the dates, all-day events and recurring series have been checked. If the source calendar is something that keeps changing, stop importing altogether and add it by URL instead, and the FAQ covers how a desktop calendar handles subscribed feeds alongside personal events.