Add to Google Calendar link
Google Calendar accepts a prefilled event through a plain URL. No API, no key, no OAuth. Get the parameters right and one click drops your event into someone else's calendar with the title, time and location already filled in.
Rather not build the URL by hand? The generator does all of this, including the encoding.
Generate a linkThe URL format
Every add to Google Calendar link is built on one endpoint:
https://calendar.google.com/calendar/render
?action=TEMPLATE
&text=Q4+product+webinar
&dates=20260910T140000/20260910T150000
&ctz=Europe/Brussels
&details=A+45+minute+session+with+live+Q%26A
&location=https%3A%2F%2Fmeet.google.com%2Fabc-defg-hijOnly action=TEMPLATE, text and dates are required. Everything else is optional, and every value has to be URL encoded.
Every parameter
| Parameter | What it does |
|---|---|
action | Always TEMPLATE. Tells Google to open the event composer. |
text | Event title. |
dates | Start and end, separated by a forward slash, in YYYYMMDDTHHmmSS form. |
ctz | IANA timezone, for example Europe/Brussels. Use it with local times, never with UTC times. |
details | Description. Basic HTML is accepted, so a link inside it stays clickable. |
location | Address or a meeting URL. |
recur | A recurrence rule, prefixed with RRULE:, for example RRULE:FREQ=WEEKLY;COUNT=8. |
add | Comma separated guest email addresses. Only works for accounts allowed to invite. |
crm | Availability: BUSY, AVAILABLE or BLOCKING. |
The timezone mistake almost everyone makes
This is the single most common bug in add to calendar links, and it is worth understanding because it looks fine in testing.
If you send UTC timestamps, so with a trailing Z, and a ctz parameter, Google converts the times correctly but labels the event (GMT+00:00) Coordinated Universal Time. The event lands at the right moment, yet anyone who opens it sees a timezone that has nothing to do with the event. People then "fix" it manually and end up at the wrong hour.
Two combinations are correct. Pick one:
- Local time plus zone.
dates=20260910T140000/20260910T150000&ctz=Europe/Brussels. NoZ. This is what you want in almost every case: the event reads as 14:00 Brussels time, and every attendee sees it converted to their own zone. - UTC only.
dates=20260910T120000Z/20260910T130000Zand noctzat all. Correct, but the composer shows UTC while the person is deciding whether to save.
The wrong combination is UTC timestamps together with ctz.
All-day events
Drop the time part and use date-only values. The end date is exclusive, which trips people up constantly: an event that runs 10 to 12 September needs an end of the 13th.
&dates=20260910/20260913Leave ctz off for all-day events. A date has no timezone, and adding one can shift the event by a day for attendees on the other side of the date line.
Recurring events
Google accepts a standard iCalendar recurrence rule through recur. The RRULE: prefix is required:
&recur=RRULE%3AFREQ%3DWEEKLY%3BBYDAY%3DTU%3BCOUNT%3D8That gives eight weekly instances on Tuesdays. Common building blocks: FREQ=DAILY|WEEKLY|MONTHLY|YEARLY, INTERVAL=2 for every other one, COUNT=n for a fixed number, and UNTIL=20261231T000000Z for an end date.
Making the link on mobile behave
On Android, calendar.google.com links open in the Google Calendar app automatically. On iOS they open in the browser, and the visitor needs to be signed into their Google account for the event to save. That is out of your control, which is exactly why you should always offer an .ics download alongside the Google link. Apple Calendar users on iOS get a native "Add" sheet from the file, and nobody has to sign into anything.