How to Import an ICS File into Google Calendar

Importing an .ics file into Google Calendar takes four clicks, but only from a desktop browser: open calendar.google.com, click the gear icon and choose Settings, open Import & export in the left sidebar, click "Select file from your computer", pick the destination calendar, and press Import. Google confirms with a line like "3 out of 3 events imported". Everything that goes wrong falls into a handful of categories, and this guide covers each one: importing versus subscribing, what happens to recurring events, why the mobile apps have no import button, and what the vague error messages actually mean.

The desktop import, step by step

• Open calendar.google.com in a browser and sign in to the account that owns the destination calendar.
• Click the gear icon in the top right, then Settings (not "Settings for my calendars").
• In the left sidebar, click Import & export. The Import panel is at the top.
• Click "Select file from your computer" and choose your .ics file. Google also accepts .csv files exported by Outlook and .zip archives produced by Google Takeout.
• Pick the destination calendar in the "Add to calendar" dropdown. Only calendars you own, or on which you have "Make changes to events" permission, appear here.
• Click Import and wait for the confirmation counter.

The counter is worth reading carefully. If it says "12 out of 40 events imported", the file parsed but 28 events were rejected individually: usually they lack a DTSTART, carry a malformed RRULE, or duplicate the UID of an event already on that calendar. Google does not say which, so validating first saves time.

Importing versus subscribing: two different things

This is the distinction that causes the most confusion. Importing copies the events into your calendar once. From that moment the copies are yours: you can edit them, delete them, and move them, and they will never change again on their own. If the publisher updates the schedule, your calendar keeps the old version until you import the new file.

Subscribing points Google at a URL that serves an .ics file, and Google re-fetches it periodically. To subscribe, click the "+" next to "Other calendars" in the left sidebar and choose "From URL", then paste an http or https address that returns the raw iCalendar text. The events are read-only in your calendar and they update whenever the source changes. The trade-off is refresh latency: Google decides its own polling interval, commonly somewhere between a few hours and a full day, and there is no supported way to force a refresh. Removing the subscription and adding it again is the only reliable workaround.

What happens to recurring events

Google imports a recurring series as a single event with its RRULE intact, not as hundreds of separate entries. That is the behaviour you want: editing the series afterwards edits every occurrence. Three details decide whether it works.

UNTIL must be in UTC when DTSTART carries a TZID

RFC 5545 is explicit here: if DTSTART is a local time with a timezone reference, the UNTIL part of the RRULE must be written as a UTC date-time ending in Z. A file that writes UNTIL=20261231T235959 alongside DTSTART;TZID=Europe/Madrid is invalid, and Google may drop the series or import only the first occurrence.

Exceptions need their parent in the same file

Cancelled occurrences travel as EXDATE lines inside the master VEVENT. Modified occurrences travel as separate VEVENT blocks that share the master UID and carry a RECURRENCE-ID pointing at the original slot. If the master event is missing from the file, those overrides arrive as orphans, and Google either discards them or turns them into standalone events on the wrong date.

Reimporting updates rather than duplicates, but only sometimes

Google matches on UID within a single calendar. Import the same file twice into the same calendar and the second pass updates the existing events instead of doubling them. Import it into a different calendar in the same account and you get a second copy, because the match is scoped per calendar. That is the mechanism behind most duplicates after an import.

Why you cannot import on a phone

The Google Calendar apps for Android and iOS have no import function. Their settings screens cover notifications, default view, and per-calendar colours, and that is all. The import UI lives only in the web client, and visiting calendar.google.com on a phone serves the mobile web version, which also omits it.

There are two workarounds. Open the browser menu, tick "Desktop site" and reload: the full Settings page loads, the file picker opens your phone storage, and the import works, though the layout is cramped. Or open the .ics as an email attachment. Gmail on Android shows the events with an "Add to calendar" prompt, and iOS offers "Add All" through Apple Calendar, which syncs to the Google account if it is configured on the device. Neither route lets you choose the destination calendar as precisely as the desktop import does.

How many events can you import at once

Google does not publish a hard per-file event count, but the import path is not built for bulk migrations. Files with a few hundred events import in seconds. Files with several thousand routinely stall, time out, or come back with a generic failure, and the browser tab does the parsing, so a slow machine makes it worse. Google also applies a daily ceiling on how many events an account can create, so a very large import can succeed partially and then start rejecting the rest.

The practical approach for a large calendar is to split it into chunks of roughly a thousand events, or by category, and import them one after another. Because Google matches on UID, a chunk that fails halfway can be re-imported without producing duplicates.

Choosing the destination calendar

Never import into your primary calendar on the first attempt. Create a new calendar first, from Settings, "Add calendar", "Create new calendar", and import there. If the timezones are wrong or the file turns out to be full of junk, you delete the whole calendar in one click instead of hunting down individual events. Once the result looks right, you can move events across or simply keep the new calendar and colour it.

Some calendars never appear in the dropdown: subscribed calendars, Holidays, Birthdays, and any shared calendar where your permission is "See all event details" rather than "Make changes to events".

"Unable to process your request" and the other errors

Google returns the same unhelpful message for most parse failures. In order of frequency, these are the causes worth checking:

• The file is not really an .ics. A download saved as invite.ics.txt, or an HTML error page saved with an .ics extension, fails immediately. Open it in a text editor: the first line must be BEGIN:VCALENDAR.
• Missing required properties. RFC 5545 requires VERSION:2.0 and PRODID on the VCALENDAR, and a UID and DTSTAMP on every VEVENT. Script-generated files often skip PRODID or DTSTAMP.
• Wrong encoding. Anything other than UTF-8 breaks on the first accented character. Latin-1 exports from legacy systems are the usual offender.
• Broken line folding. Lines longer than 75 octets must be split with CRLF followed by a single space. A script that wraps with plain newlines produces properties Google cannot parse.
• Mixed line endings. The spec requires CRLF; files saved with bare LF sometimes survive and sometimes do not.
• A .zip that contains folders. Takeout archives import fine; a zip you built yourself with a nested directory does not.

If you would rather not audit the file by hand, iCalConverter.com has a Google Calendar optimization tool that rewrites an .ics into the shape Google's importer accepts: it normalizes timezone identifiers to IANA names, re-encodes as UTF-8 with correct CRLF folding, fills in missing UID and DTSTAMP values, and repairs RRULE definitions where UNTIL and DTSTART disagree. Everything runs in the browser, so the file never leaves your machine.

Bottom line

Import from a desktop browser, into a throwaway calendar created for the purpose, after checking that the file opens as plain text starting with BEGIN:VCALENDAR. Subscribe by URL whenever somebody else maintains the schedule. And when Google refuses a file without saying why, the cause is almost always encoding, folding, or a missing required property.