Ops drops the meeting passcode into the calendar description, titles the event “tonight’s cutover,” invites the whole group, and books a room. After the call they open their own calendar and hit delete. The assistant’s shared copy still has the description. Anyone who can open the room resource calendar can open the same paragraph. Ten minutes before the slot, a reminder pops: the lock screen shows the word “password” and the line after it.
An earlier piece covered if you put a temporary password in an email, what Sent, forwards, and phone previews still keep: that is “once the password is in the body, can Sent and the notification shade still show it.” This piece asks a different question: once the password is in a calendar invite’s description, which leftover copies can you still open. If the secret instead travels on a one-time link, the shape is still s.html?id=…#…. Create and read need no account. MyPassGen’s tools open without sign-up. This is not a tour of calendar buttons. It is a walk through official help pages and what you can see in event details, sharing permissions, and the notification shade.
Split two things first
Private hides the event from people who look at your whole calendar. It does not hide it from guests you invited into this event. Guests open the event itself. The password in the description is visible to them. Deleting your copy does not empty guest copies, a room resource calendar, or a lock-screen reminder.
Why deleting your event does not erase the password
A calendar invite is not a sticky note that lives only in your window. RFC 5545 §3.8.1.5 defines DESCRIPTION as a text property on a calendar component: it gives a VEVENT a fuller note than the title. Once a password sits in that field, it is part of the event data. It travels with the title, time, and location. It is not trapped in the box you clicked Send on.
What you send is usually a scheduling request, not a one-way notice. RFC 5546 describes REQUEST as taking an iCalendar object and scheduling it with other calendar users. Receivers reply with a reply method. A meeting request is one of the listed examples. Each invited person gets a copy they can write into their own calendar. Deleting the organizer’s row in the web UI changes only that account. Guest calendars, and the offline copies already synced to a phone, do not vanish with it.
People who do not use Google Calendar often still get an invitation email. Google’s Invite people to your Calendar event says you can invite any email address, and the other person receives an invitation email. Non-Google Calendar users, and people who use Google Calendar with a non-Gmail address, get an email that then updates their schedule according to their own calendar service. So “I only made a calendar event, I never wrote a separate mail” does not mean there is only one plaintext copy. The invite itself can drop another copy into an inbox. Where a password in an email body still lives was the earlier article. This one does not repeat that map.
Who Private actually blocks
Google Calendar gives a single event three visibility settings: default, public, and private. Change event & task visibility is explicit. Default follows the calendar’s sharing settings. If a colleague has See event details or higher, they can find the details. Private shows most people who look at your calendar a block labeled Busy. The exceptions are you, and people you have given Make changes to events and see event details or higher. It blocks people who view your calendar. It does not block guests you invited into this event.
The same page lists boundaries that are easy to miss. After you invite someone, they control how the event appears on their calendar. If the event is default visibility and they have shared their calendar, those people can find the event details on the invitee’s calendar. If you book a meeting room or another resource, people with access to that resource calendar can find the details too. Even when the event is private, inviting guests or booking a room can still expose the start time, end time, and creator. A recurring series can have only one visibility. Changing one instance applies to the whole series. Google’s July 2026 Workspace update restated that last rule: you can no longer set a different visibility on a single occurrence.
Outlook’s Private flag is not burn-after-read either. Microsoft’s Share your calendar in Outlook on the web says items marked private are protected: most people you share with see only the time, not the title, location, or other details. A recurring series marked private still shows the recurrence pattern. The exception is a delegate you allowed to view private events. Microsoft’s Make an appointment or meeting private page adds the other half: after you mark it private and send the update, the details remain visible to you and the meeting attendees. Putting a meeting password in the description and hoping the word Private will sweep it up does not match those clauses.
Shared calendars, rooms, and the secret address
Sharing the whole calendar reaches further than a single Private flag. Google’s Share your calendar defines See event details as: the other person can find all details, such as event names, times, places, and descriptions. On a work or school account, an administrator can have special permissions that let them find your calendar and every event detail even if you never shared it. If you make the calendar available to the public, other people can find it on the web or in search results, and they can subscribe with other apps. A password in the description is plaintext for everyone who has See event details, and for any admin view that exists in your tenant.
There is also a dedicated sync door. Google lets you attach a calendar as read-only to Outlook or Apple Calendar through an iCal link, and it labels that link a secret address. Sync your calendar with computer programs says only you should know the secret address; do not share it; if you already did, click Reset. Whoever holds that URL can subscribe to the whole calendar. A meeting password in a description rides the subscription. They do not need to be on the guest list.
Apple’s public share is a whole-calendar copy as well. The iCloud help page Share a calendar on iCloud.com says that when you share publicly, invitees automatically receive an email that includes the calendar URL, and the other person does not need to be an iCloud user to view it. Outlook on the web caps outside sharing at Can view when I’m busy, Can view titles and locations, and Can view all details. People outside the organization do not get edit or delegate, but Can view all details is already enough to read a description. A room resource calendar, a team subscription, and a secret address are three places your Delete click does not clean up.
Where reminders, lock screens, and forwarded invites differ
Once the same password is in the description, a reminder can show it again. Google lets you add up to five notifications on one event. Reminders sent to Google Calendar guests follow their settings, not the ones you set. Non-Google Calendar guests may receive the notifications you configured, or the ones they chose in their own service. The popup usually carries the title. Some skins also show the first lines of the description. If the password is the first sentence, or the title is “password is xxx,” the preview is plaintext for anyone who can see the screen.
The lock screen is another window. Apple’s iPhone User Guide Access features from the iPhone Lock Screen says notification previews can include text from Messages, lines from Mail, and details about Calendar invitations. Show Previews can be set to Always. With previews on, you do not need to unlock to see the words the system thinks are worth lighting up. After you delete your own event, guest phones still fire on their own reminder settings.
Forwarding makes another copy. Google marks this Important on the invite help page: if you forward an invitation, the recipient might see updated meeting details and could change your RSVP at any time. If guests may add other guests, forwarding the invite to a new person adds them to the guest list after they respond, and they can invite more people. If you do not want guests to invite others, turn off Invite others on the event. Zoom treats the full invitation text as something you paste into a calendar: official help Where to find the meeting invitation text is about copying the entire invitation so you can paste it into an email or a calendar invite. The join link and the passcode travel in that block. Meeting software writing a passcode into a description is not a bad habit of one team. It is a field this handoff path already carries.
Booking a room is not an extra layer of secrecy
Resource calendars often grant See event details to a front desk, an assistant, or a whole floor. A default-visibility event puts its details on the resource calendar. Private still fails to hide start time, end time, and creator. Who else can read a password after you copy it from a generator is in Who else can read the clipboard after you copy a password. Do not treat a passcode as ordinary agenda text in the same description.
What leftover a calendar password still has
Use the same test password and the same title. Send a normal invite, mark one private, share a whole calendar, then forward an invite. The pages you can open are not the same. The table below is written as “places you can click,” not as product names.
| What you did | Your own calendar | What others often still have |
|---|---|---|
| Password in the description, then you delete your event | Your side may be empty; search first | Guest copies, the invitation email, and a synced phone event can still hold the original |
| Marked private, guests still invited | You can still read the description | Guests can read the description; people who only view your calendar usually see Busy |
| Whole calendar shared as See event details | The original event is still there | Shared people can read the name, time, place, and description |
| Booked a room, or published a secret iCal address | The original event is still there | The resource calendar or a subscriber can read details; a forwarded secret address subscribes the whole book |
| Description holds only the one-time id; the key goes by phone | The calendar has no key after # |
Reminders and shares cannot assemble a full credential; both halves are required to decrypt |
Do not mix the fifth row with the first four. If you paste a full s.html?id=…#… into the description, guest copies, shared calendars, and lock-screen reminders still hold one complete credential. The server still cannot see the key. A reminder bot usually cannot read the slice after #. A person can copy the whole string. Split the id from the key, and a calendar search cannot find a link that opens. Treat a full link as the password itself. Do not store it in a calendar or a bookmark.
Check it on the spot
These steps do not depend on a brand promise. Use a test password that will never log into a real account, for example orange-lake-7. Title the event “test — do not open production.” Do not rehearse with a master password you still use, a production key, or a live one-time link.
- On a personal test calendar, create one event whose description is only the test password, and invite a second test mailbox. After send, open the guest calendar and confirm the description is there. Open the phone calendar notification and see whether the lock screen or shade shows the test password or the title. Do not use a production work calendar for this step.
- Search the calendar for
orange-lake-7. A hit means the description was indexed. Note every door that still opens: organizer calendar, guest calendar, invitation email. Delete the organizer event, then search again: does the guest calendar or All Mail still hit? - Check Google visibility: set the same test event to private. Open your calendar from a test account that has See event details but not change permission. You should see Busy. Open the event itself from the invited test account. The description should still be there. This only proves “Private ≠ hidden from guests.”
- If you have a disposable test calendar, share it with another test account as See event details. Open their view and confirm the name, time, and the test password in the description are all there. On a work or school account, also ask whether an admin can view details without a share. Trust your tenant’s actual setting, not a product slogan.
- Open calendar settings for Integrate calendar / Secret address. Confirm the help page says not to share it. Do not paste that address into a chat as a test. If you already did, Reset it from the help page. Create one more event that holds only the test password, and watch the lock-screen preview. On iPhone, Settings → Notifications → Show Previews tells you whether the current value is Always, When Unlocked, or Never.
- Create a MyPassGen one-time link with the same test sentence, expiry 24 hours, reads left at 1. In the calendar description, paste only the part before the hash,
s.html?id=…. Speak the key on a call or in person. Opens without an account. With only the id, the recipient should see an incomplete link; both halves are required to decrypt. After reading, overwrite the clipboard. Do not store an address that still has#in a calendar.
On a company calendar, add half a step: open the room resource calendar for the test event and see whether the description still holds the test password, and whether an assistant’s shared calendar synced the same paragraph. MyPassGen will not tell you whether a given gateway stored another copy. Trust the windows you just opened.
If calendar is the only channel, split the credential
For a one-to-one handoff the other person can open now, do not put the password in the description. Generate it on this device, then wrap it in a one-time link. MyPassGen’s password generator uses a random mode of 6–128 characters, default 16, and warns below 8. It opens without an account. The result is not uploaded as business data. On create, the browser encrypts with AES-256-GCM. A single note caps at 32 KB. Reads default to 1 and cap at 10. Expiry can be 1 hour, 24 hours, 7 days, or count-only with no TTL. The server parks ciphertext only. Why the key belongs after # is in When you send a password once, why the decryption key belongs after # in the URL.
When a calendar is required, split the channel. The event carries only the time, the place, the id, and the sentence “key by phone.” Do not paste a full link into a description that will sync, share, and draw a lock-screen preview. A call, an in-person handoff, or a different messenger account carries only the slice after #. Neither half decrypts alone. That is a usage pattern, not a product default. The create page still emits one full link, which is convenient for a one-to-one send. For a channel that draws preview cards, run a test link first and see whether the preview counts a read before you send a live secret. See If you paste a one-time link into Slack or WeChat, does the preview burn it first.
A certificate pack or export larger than 32 KB does not belong on a one-time text link. Use the file encryption box: streaming AES-256-GCM in the browser, one file up to 5 GB, output .lock / .enc, passphrase sent separately. Drive or a calendar attachment should hold ciphertext only. See Before you drop a file in the cloud, who can read the plaintext. An unencrypted spreadsheet attached to a calendar event is the same class of problem as a password in the description: the file rides guest copies and every forward.
After you have checked “does the guest calendar still hit after I delete the organizer event” and “does the lock-screen preview show the test password,” you can answer this article’s question: once a password is in a calendar description, guest copies, shared calendars, room resources, and phone reminders can all show the plaintext again. Private blocks people who view your calendar, not guests. A secret address or a public share subscribes the whole description. A calendar is a fine channel for a time and an id. It is a poor channel for the password itself.
FAQ
If I delete my event, can the other person still see it?
Emptying your row does not empty theirs. The invite copies to them as an RFC 5546 REQUEST. Search the test password: guest calendar, invitation email, and the phone notification. If they already forwarded it, or a resource calendar still holds it, deleting your event does not apply. Do not treat “I deleted the event” as a password rotation.
Can Private stand in for a one-time link?
No. Google writes that Private shows Busy to people who view your calendar; guests can still open the description. Booking a room can still expose start time, end time, and creator. Outlook hides title and details from most people you share with, except a delegate allowed to view private events, and attendees still see the details. The body is hosted by the calendar service. Plaintext does not appear only in the recipient’s browser. To check “did the server see anything besides ciphertext,” use a one-time link and Network. Do not substitute Private.
How is a full one-time URL in the description better than the password itself?
Server logs and HTML-only previews usually cannot see the key after #, and the read page waits for script to fetch ciphertext before it counts. Guest copies, shared calendars, and a lock-screen reminder can still hold the whole URL. Whoever copies it can open it before it burns. Safer: put only the id on the calendar; send the key on another channel.
Do create and read need an account? If I send the wrong channel, can support recover it?
No sign-up. Create and read are public to a visitor. After ciphertext burns by count or expiry, there is no server-side plaintext backup and no support inbox that can recover it. Generate a new password and a new link. Do not keep refreshing the same URL to see if it comes back.