Duplicate an event in Google Calendar instead of typing it again

The same meeting has to go on the calendar again. Same title, same length, same room, same three people, different day. Typing it from scratch takes a minute, and doing that eleven times in an afternoon while planning a quarter is the kind of work that makes a calendar feel like a chore rather than a tool.

Google Calendar does not have one duplicate feature. It has three different mechanisms that each cover part of what people mean by the word, and picking the wrong one produces either an event that is not really a copy or a series that cannot be edited the way the next change will need. This sets out which mechanism does what, what each one drops on the way, and why the keyboard shortcut everybody looks for is not there.

Three different requests hide behind one word

Before touching a menu, it is worth deciding which of these is the actual goal, because the right mechanism differs for each.

What is wanted	The mechanism that fits	What the result is
The same meeting on a schedule	Recurrence	One event with many occurrences
The same event visible on a second calendar	Copy to another calendar	Two separate events
A starting point for a similar but different event	Duplicate a single event	Two separate events, then edited

The second and third produce independent events. The first does not, and that difference decides how much work the next change costs. A weekly review created as fifty two separate copies takes fifty two edits when the time moves. Created as one recurring event, it takes one, with a prompt asking which occurrences the change applies to.

The other way this matters is deletion. An occurrence of a recurring event can be removed on its own, leaving the rest of the series in place, and Google's own help lists that as one of the choices offered when a repeating event is deleted. Fifty two loose copies have no series to leave in place, so cleaning up a cancelled programme means selecting and deleting each one.

The copy Google documents: one event onto another calendar

This is the mechanism with a documented path, and it is the one to reach for when the same commitment needs to exist in two places, for example on a personal calendar and on a shared team calendar.

Open the event, use its options, choose the destination calendar, and save. The result is a second event on the destination calendar while the original stays where it was.

Moving is the operation people reach for by mistake. Google Calendar also offers a way to put an existing event on a different calendar by editing it and changing the calendar in the event's own dropdown. That relocates the event rather than copying it. The original disappears from the source calendar, and for a transfer between owners Google is explicit that the event's organizer changes. Anyone expecting two events after that step finds one in a new place.

Two limits are documented on this route and both are worth knowing in advance. An event with more than 200 guests cannot be transferred to another owner or calendar. And when an event carrying a video meeting link is transferred, the video conferencing policies that apply to that event are affected as well, which is a real consideration for anything involving people outside the organisation.

Duplicating one event as a starting point

The third request is the everyday one. An event already on the calendar has the right length, the right guests, and the right description, and what is needed is a near copy with one thing changed.

Google Calendar's interface supports duplicating an event one at a time. What it does not support is doing that in bulk, and the distinction is the whole reason this task feels slow. There is no way to select six events and duplicate them into next week. Each one is a separate pass through the same menu.

The Calendar API shows the same shape from the other side. The operations it offers on events are create, read, update, patch, delete, move, list, instances, quick add, and import. There is no duplicate. The closest thing is import, which Google describes as adding a private copy of an existing event to a calendar, and that operation requires the event's unique identifier to be supplied rather than generating a fresh one. It is built for bringing an event in from another system, not for producing a second copy alongside the first.

That matters for anyone considering automation. A script that genuinely duplicates events has to read the original, then create a new event from its fields, because there is no copy call to invoke. Every extension and automation service that advertises duplication is doing exactly that.

Why there is no keyboard shortcut for it

This is one of the most searched questions on the topic, and the answer is short. Google publishes the full list of Google Calendar keyboard shortcuts, and duplicate is not in it.

The list has to be switched on first, in settings, by enabling keyboard shortcuts. What it then covers, for event work, is creating a new event with c, opening the details of a selected event with e, saving with ⌘S on a Mac, deleting with Backspace or Delete, undoing the last action with z, and closing the details view with Esc. Pressing ? shows the whole list.

Nothing in there duplicates. The practical consequence is that the fastest documented path for making a near copy is e to open the event, read what is in it, Esc, then c to create a new one and retype the parts that matter. That is not a copy, which is why two of the pages currently ranking for this search are browser extensions whose entire purpose is to add the missing command.

The absence also explains a pattern worth avoiding. Because there is no quick copy, people reach for recurrence to get repetition they do not really want, then edit individual occurrences until the series no longer resembles a series. A series edited that way still behaves as one when something is changed or deleted at the series level, and the prompt asking which occurrences a change applies to becomes a genuine risk rather than a formality.

What a duplicate quietly leaves behind

A copy is rarely a complete copy, and the gaps follow a pattern.

Guests and their replies. When events travel as a file, through export and import, Google states plainly that guests are not imported, and neither is conference data. A copy that arrives with no attendee list is not a scheduling failure, it is the documented behaviour. Even where guests do come across, the replies are the fragile part: an accepted response on a copied event is a claim about a conversation that happened around the original.

Event types that are not ordinary events. Google Calendar classifies events by type, and the set includes birthday, focus time, events from Gmail, out of office, and working location alongside the ordinary default type. Copying a focus time block and expecting the copy to defend itself against invitations the way the original does is a reasonable assumption and a wrong one. The behaviour belongs to the type, and a copy that lands as an ordinary event is a coloured block with no behaviour attached.

Reminders. Default reminders belong to a calendar and to the person reading it, not to the event. An event copied onto a different calendar picks up that calendar's defaults, so a meeting that gave a ten minute warning in one place can arrive silent in another.

The identifier. Every event carries a unique identifier, and for a recurring event all occurrences share one while each has its own internal id. Anything that produces a copy while keeping the original identifier is not creating a second event so much as offering a second opinion about the first, which is the mechanism behind imports that appear to do nothing.

A copy is therefore a good carrier of times, titles, and descriptions, and a poor carrier of everything social or behavioural. Deciding which of those the copy is for takes a second and saves an argument later.

Duplicates that appear without being asked for

The same search term brings a second group of people: those seeing two of everything and wanting it to stop. The causes are a short list.

The most common is the same account connected twice. Two addresses that resolve to the same mailbox, for example a primary address and an alias, are treated as two accounts, and every event in them appears twice.

The second is being both a subscriber and a guest. An event on a shared calendar that also invited the reader personally exists twice by design, once on the shared calendar and once on the personal one. Hiding one of the two calendars is the fix, not deleting anything.

The third is an import that ran twice against events whose identifiers had been rewritten in between. Identifiers are what stop a second import from landing as a second set of events, so anything that changes them removes that protection.

The distinction worth holding on to is that none of these are bugs in duplication. They are two sources for one commitment, and the repair is at the source rather than in the calendar grid.

Choosing between the routes

Route	Original stays	Independent copy	Good for
Recurrence	It becomes the series	No, occurrences of one event	Anything on a rhythm
Copy to another calendar	Yes	Yes	One commitment, two calendars
Duplicate a single event	Yes	Yes	A template for a similar event
Move to another calendar	No, it leaves	Not a copy	Filing, not copying
Export and import a file	Yes	Only with rewritten identifiers	Moving between systems

Read down the second column and the shape of the decision is clear. The only routes that leave the original alone and produce something editable on its own are the middle two, and both are one event at a time.

That ceiling is the reason this task is worth solving at the point of entry rather than at the point of copying. An event that takes eight seconds to create from a typed line does not need to be duplicated, because creating the next one is faster than finding and copying the last one. Some Mac calendars parse a sentence such as a day, a time, a place, and a guest into a complete event, and offer a duplicate command in the event's own context menu for the cases where a copy really is the shortest path. How that entry step works is set out in entering events, and the fuller list of what a desktop calendar handles is in features.

What to change first

Decide whether the repetition has a rhythm. If it does, make it a recurring event and accept the prompt about which occurrences a change applies to, because that prompt is what saves the next fifty edits. If it does not, duplicate the single event and expect to re-add guests and check the reminder. And if the copying is happening because entering an event from scratch is slow, that is the part worth replacing, which is what Caltimate is built around.