Who can still see a password — and the key after # — in a screenshot or screen share

An operator mints a database password, hits Win+Shift+S, and drops the image into chat so a colleague can confirm the characters. Or they join a standup, pick Entire screen, and leave a one-time link sitting in the address bar. Neither action shows up as a business request in the Network panel. Both can hand the plaintext — and the key after # — to a second person, a second device, or a recording someone will scrub later. A previous piece covered who else can read the clipboard after you copy a password. This one switches paths: while the secret is still on screen, who does a screenshot or a screen share give it to.

This is not a tour of the password generator, and it is not a feature list for the one-time-link create page. The question is one sentence: which files, which sessions, and which albums still hold the password and the full URL after you capture pixels. MyPassGen prints the generated string as visible text, not as dots. After a one-time link is created, the full s.html?id=…#… string is shown on the page. Every tool opens without an account. Network can prove the request line never carried the fragment. It cannot prove the screenshot is empty.

Secrets in pixels: the page and the address bar

The password on a generator page is not a type="password" field. It sits in a result list. Anyone who can see that rectangle can read the characters. That is so you can check the string, not so a screenshot is blocked. Dots only hide a glance from the next desk. A pixel copy does not care whether the control “looks like a password box.”

A one-time link puts the decryption key after #. The shape is …/s.html?id={id}#{key}. RFC 3986 §3.5 says the fragment identifier is for the user agent; it is not sent when the resource is retrieved. RFC 9110 §10.1.3 goes further: a Referer header must not include the fragment or userinfo. So access logs and Referer traces can miss the key, and the screen can still show it. The same RFC’s security notes are blunt: the fragment stays off the request, but it remains visible to the user agent, to extensions, and to script that runs in the response.

The address bar is the display surface for the whole URI, including #. Browser history also stores the entry with the fragment, so Back can return you to the same string. Another article explains why the decryption key belongs after #: so it never rides the HTTP request line. Screenshots, screen shares, and meeting recordings sit on a different layer. They copy the pixels you can see. They do not read the HTTP spec.

After MyPassGen creates a one-time link, the result area writes the full URL. Copy uses navigator.clipboard.writeText. Create and read both open without a sign-in. What you check is whether that string appears in a Desktop PNG, in the phone’s Screenshots album, or in the address bar of a meeting playback — not the sentence “the server cannot see plaintext.”

Where a screenshot lands

A screenshot is not “done” when it appears in the chat compose box. The operating system writes a file or the clipboard first. You paste second. The file is harder to take back than the message.

Mac: Desktop by default

Apple Support is specific: Shift-Command-3 captures the entire screen; Shift-Command-4 captures a selection. By default the file lands on the Desktop with the name “Screen Shot [date] at [time]”, as PNG. Anyone sitting at that Mac can open it. Time Machine and Desktop & Documents in iCloud will pick it up if those are on. Hold Control as well — Control-Shift-Command-3 — and the capture goes to the clipboard instead of the Desktop. That path is the previous article.

Windows: Pictures library and the clipboard

Win+PrtScn writes a full-screen PNG into the current user’s Pictures\Screenshots folder. Win+Shift+S first puts the selection on the clipboard. If Snipping Tool has “Automatically save screenshots” on, the same image also lands in Pictures\Screenshots. With clipboard history on, Win+V can show up to 25 items, and a screenshot counts as one. If OneDrive is backing up Pictures, that PNG follows the account. Deleting the copy in chat is not enough. Disk and the cloud can each keep one.

iPhone: the Screenshots album, then iCloud Photos

A system screenshot goes into the Screenshots album in Photos. With iCloud Photos on, photos and videos upload in their original format. A screenshot is a photo. Another device on the same Apple Account will show the address bar and the password in that album after sync. Deleting the local tile does not instantly clear the cloud or the other devices. Recently Deleted usually needs a second pass.

Entire screen, a window, or a tab

Chrome’s Screen Capture API splits shareable surfaces into three kinds: a tab (browser), a window (window), and a whole screen (monitor). Meeting pickers usually map onto those three. The difference is not “whether the meeting stream is encrypted.” It is how large a rectangle of pixels you chose.

Share the current tab and the far side mostly sees that page. Whether the address bar is in frame depends on whether the meeting client includes the browser chrome; many implementations push page content only. Share a window and the title bar, the address bar, and the bookmarks bar go with it. Share the entire screen and the taskbar, other desktops, a toast in the corner, and a later SMS code all go in.

Zoom’s own help is direct: when you share the entire screen, participants can see everything you view on that desktop or phone, including apps you open and files you look at. Microsoft Teams turns on Do not disturb while you present for a reason — a notification that pops during a whole-screen share is now in the meeting. Those product notes are written for presenters. The technical fact is the same on a quiet internal standup: whole-screen share does not auto-mask a password field.

From Chrome 119, getDisplayMedia accepts monitorTypeSurfaces: "exclude". A meeting page can drop the Entire Screen pane so staff are less likely to pick the whole display. As the sharer, you may still see that pane. Picking it by habit bundles the generator page, the address bar, and system toasts for everyone in the room.

Recordings, album sync, and chat history

After the live share stops, the pixels often remain. Cloud recordings, a local movie, and an image in chat outlive a thirty-minute call.

A meeting product’s cloud recording stores the shared frame. Scrub the playback after you hang up and the one-time URL in the address bar, or the password in the result list, is still readable frame by frame. Host-side playback permissions only decide who can open the file. They do not decide whether a person who opens it can read the pixels from that minute. A local recording — Shift-Command-5 on a Mac, Xbox Game Bar on Windows — is a second file, usually under Movies or Videos, and a drive-sync client can pick that up too.

Once a screenshot is in instant messaging, it sits in the other person’s history, in the vendor’s attachment store, and sometimes in “extract text from image.” You can delete your side. They still have a copy. That is a different layer from “did the page upload the password.” The generator can show an empty POST in Network. The PNG you sent did not use that business API.

Two more rooms get skipped. A conference-room TV with AirPlay or HDMI is a second camera for anyone in the back row. A remote-desktop session with clipboard redirection can drop the screenshot file on both ends. None of that appears in the generator’s Network log.

Four paths, side by side

The same test password or test one-time link, once it is on screen, splits into at least four “who can see it” paths. The algorithm name does not change. The place the pixels were copied does.

A generator that draws the string with Web Crypto, and a Network panel with no password body, only closes the upload path. The four rows above stay open. If a password manager can autofill, there is no reason to lay the password on screen for someone else. When a person must see it, crop the smallest rectangle, or send a one-time link as text. Do not capture the whole display.

Check it on the spot

None of the steps below depends on a brand promise. Use a password that will never unlock a real account, and a one-time note that only holds a test sentence. Do not practice with a live master password or a secret that has not been burned.

1. Open the generator and mint a default 16-character test password. Do not copy it. Do not sign in with it. Look at the result list: the characters are visible, not dots. Open DevTools Network, enable Preserve log, and confirm that after generate the request bodies do not contain that string. How to check uploads is in How to verify that browser encryption did not upload plaintext.
2. Take one full-screen system screenshot. Open that PNG on the Desktop or in Pictures\Screenshots and confirm the test password and the address bar are both in the image. Then crop the result list, leave the address bar out, and capture again. The second image should not show a full one-time URL or an unrelated window.
3. On an iPhone, or any device with iCloud Photos on, open Photos → Screenshots and see whether the capture is there. If a second device uses the same Apple Account, wait for sync and open the same album there.
4. On Windows with clipboard history on, press Win+V and see whether the screenshot is in the list. Do not pin it. Use Clear all, or keep copying junk, until the image is gone from the list.
5. Start a meeting with only yourself. Share the entire screen first. From a second device or a colleague, check whether the address bar and the result list are in frame. Switch to the current browser window or the current tab and compare: are the toasts and the taskbar still there. If cloud recording is on, hang up and scrub ten seconds of playback.
6. When a remote colleague needs a short secret, switch to a one-time link: plaintext cap 32 KB, key after #, read page open without an account. Send the URL as text. Do not screenshot a frame that includes the address bar. The create request should hold ciphertext only, not the test sentence.

MyPassGen’s password generator is built on that boundary. Random mode is 6–128 characters, default 16, with a weaker warning below 8. Results are listed as visible text. Copy uses writeText. There is no account and no password vault. What you verify is the Desktop PNG, the Screenshots album, and the meeting playback — not the word “Generated” on the page.

How to close out after the capture

For the one image you must take today, finish in this order: confirm the crop has no address bar, no taskbar toast, and no second live password; then send it. After it is sent, delete the original on the Desktop or in Screenshots, clear Win+V, and empty Recently Deleted on the phone. If iCloud Photos or OneDrive Pictures is on, check a second device and delete the synced copy there too.

In a live share, stop sharing before you open the generator or the one-time read page. If you must talk through the flow, share only the current window, and first switch the browser to a compact address bar that hides the full URL, or shrink the window to the result list. Treat a demo machine and a conference TV as “someone in the back row is taking a photo.” Do not open a live one-time link there. Do not generate a master password there.

Once you crop instead of capturing the whole screen, and you delete the PNG and the playback after hang-up, you can already answer the article’s question. Who still sees the password in a screenshot or a screen share depends on how large a rectangle you chose, where the file landed, and whether a recording still exists. A generator that does not upload only means the server log does not hold that string. It does not take back the copy already written into an image and a movie.

FAQ

Does HTTPS already keep a password safe inside a screenshot?

No. HTTPS protects the hop from the browser to a server. A screenshot and a screen share copy local pixels. They do not ride that TLS session. Album sync, a meeting recording, and a PNG dropped into a group chat do not care whether the address bar shows a padlock.

If the key sits after #, does a screenshot miss it?

No. # only keeps that slice off the HTTP request and off Referer. The address bar, the create-result area, and browser history still show the full URI. A full-screen capture and a window share turn that slice into text inside an image.

Do I need an account to generate a password or create a one-time link? Does the site upload the screenshot?

No account. Generate and create should stay in the current tab. A system screenshot is the operating system writing a file. It is not a site POST. Open Network: after you capture, the request body should not contain that password. The outbound path you control is the PNG you put into chat.

Is sharing only the current tab enough?

It is one step safer than the whole screen: the taskbar and system toasts usually drop out of frame. A visible password on the current page, and a full one-time URL in the result area, are still readable on the far side. Demo the flow with test data. Send a live password on a text channel, or read it aloud in the room.