Hold this first: a hash on the host login password does not stop a password that has already become text inside a screenshot, and it does not stop a direct link assembled from an Image ID. Changing the host password only handles that one login. Live keys that appeared in a capture must be rotated on the original system. What you can check on this machine is whether the pixels you are about to send contain a readable secret—not whether the notice used the word “hash.”
Answer the search intent in one sentence
The risk of screenshotting a password onto an image host is not “was the login password hashed.” It is whether the frame itself, and the text pulled out of that frame, leave your machine as their own fields. A hash covers one column: the account passphrase. OCR text, Image IDs, upload IPs, User-Agents, and EXIF location are another set. Once those leak, an unlisted screenshot is no longer protected by “nobody can guess the link,” and a password in the picture no longer needs a hash crack first.
This note is for developers, operators, and anyone who still captures an error, a console, or a password-manager window, drops it on a screenshot host, and forwards the link. It does not replace any host’s incident notice, and it is not a guide to “turn screenshots off.” What you should leave with is which layer the published hash covers, which privacy model an Image ID breaks, why OCR is easier to search than pixels, and how to compare the payload before you upload.
What this screenshot-host notice split apart
On 16 September 2026, Gyazo’s operator posted an English notice from Helpfeel, with a Japanese version the same day. The timeline: on 11 September a third party used a vulnerability in the image-upload server to run arbitrary commands; unusual activity was spotted that evening; by the early hours of the 12th the access path was cut and the vulnerability was fixed; on the 14th they confirmed data had left and paused some image delivery; on the 15th they reported to Japan’s Personal Information Protection Commission and resumed delivery of images newly uploaded after remediation.
The 16 September notice splits the confirmed scope into two blocks. The first is about 23.62 million user-related records: a name or nickname the user typed, email, password hash, user ID, device ID, login session ID, an X integration token if connected, a Google SSO email if connected, profile, language, registration and last-login times, subscription plan, and billing status. The notice says it does not include credit-card numbers or other payment methods. Those 23.62 million records also include anonymous accounts with no registered email; the number of distinct people is still under investigation.
The second block is image metadata. Helpfeel said most of it is about 490 million rows registered in January 2019 or earlier (about 14.4% of all image-related data), plus about 2.4 million more rows pulled with a separate filter. Fields include: the Image ID used to construct the image URL, the upload-source IP, User-Agent, EXIF location if the file contained it, OCR text extracted from the image, the image title, the source URL, and a hashed passphrase for private images. In that notice, “images” include screenshots, GIFs, and videos. Helpfeel and Cosense use different systems; as of that date they had not confirmed a leak from those two. Pages that embed a Gyazo image may fail to load because delivery was paused.
This is not another “a site’s password hashes were stolen” story. The hash, the session ID, the Image ID, and the OCR text are four parallel channels. Changing only the host login password covers the first channel, and it does not stop session IDs that already left—the notice says they invalidated and restricted authentication-related data, and asked users to change the Gyazo password plus the same or similar password reused elsewhere.
A login password hash does not cover plaintext on the screen
A password hash is designed so that, after a user table is taken, an attacker cannot read the login passphrase directly and still has to spend compute guessing it. The algorithm, the salt, and the iteration count decide how hard that layer is. They do not decide whether another passphrase you captured in a picture is safe. The host account password and the production-database password in the screenshot were never the same column.
When a developer captures a terminal, a browser password field, a cloud console, or a password-manager window, the host receives pixels. Many hosts then run text recognition and store a searchable OCR string so you can find “that screenshot with the error.” Once the recognition result is in the database, passwords, connection strings, and tokens no longer live only in image bytes. They become a field you can filter by keyword. This notice listed “OCR text extracted from the image” as its own leaked metadata field. That is not a comment-thread guess. It is a formal column.
So “passwords were stored as hashes” supports a narrow claim: this host’s login passphrase is not plaintext in the user table. It does not support: an SSH private key in a screenshot still needs a hash crack; an OCR table cannot be searched for BEGIN OPENSSH or AKIA; a private image can be opened only by you. Those last claims need other evidence: whether the metadata includes OCR and Image IDs, and whether a readable secret was on screen before you uploaded.
Do not test this with a real password, API key, or unredacted connection string. Prepare a one-time test sentence, or a capture that contains only that sentence. What you check is whether the outgoing pixels and the request contain that canary—not whether you sent another credential to a host.
Why an Image ID breaks the “unlisted link” model
Many screenshot hosts implement “do not share publicly” as: keep the image off your profile, and hand you a direct link that looks like random characters. The security assumption is that without the ID, nobody can assemble the URL. That is a hidden address, not access control. Anyone who has the ID can build the same address with the same rule.
Helpfeel’s notice calls the Image ID “information used to construct the image URL,” and says a third party could use that information to view the matching images. They temporarily disabled viewing of some images for that reason. The notice also confirms that a list identifying private images was taken, and they cannot fully rule out that some private images were viewed. A list plus IDs removes the assumption “only I know this link.”
Even if a private image had its own passphrase, the notice lists a “hashed passphrase.” A hash adds a cracking step for that passphrase. It does not automatically take pixels away from someone who already has the ID while the host still serves by ID. Pausing delivery is an operator-side gate. It is not proof that the ID never left the database. Writing “I never posted the link in a group” as “the image is not in the store” mixes product-UI visibility with storage-layer visibility.
EXIF location, upload IP, and User-Agent are a third layer of context. A phone photo of a screen or a desk can carry GPS. The upload request carries an egress address and a client identifier. Even when the pixels show no street number, metadata can still reconstruct who uploaded a picture, from where, and with which client. Some capture tools strip location; some do not. “I used a screenshot, not the camera roll” does not prove EXIF is empty.
Why OCR is easier to reuse than pixels
A full PNG still needs a person, or a vision model, to find a password field in a cluttered desktop. OCR text is already a sliced string. After a leak, searching for password, BEGIN , sk-, or an internal hostname is an order of magnitude faster than paging through 490 million images. The notice does not publish recognition accuracy, and it does not need to: once the store holds “text extracted from the image,” the attacker is facing a text field, not thumbnails only.
That is also why “I set it to unlisted” does not stop the OCR layer. The visibility switch controls whether the product page lists the image. OCR controls whether the host turned the frame into words. Both can be true at once: unlisted in the UI, and a title, OCR string, and ID in the database. A dump takes the database, not the state of your share button.
This is not the same claim as “the recipient took a screenshot of a burn-after-read page.” An earlier note covers a copy on the recipient’s device, which the host cannot erase by deleting ciphertext. This note covers the sender handing pixels to a screenshot host, which then extracts text and assigns an ID. One side is “they kept a copy.” The other is “you handed it over first.” Neither is cancelled by “the link expired” or “passwords were hashed.”
| What you see | What it can support | What it cannot support |
|---|---|---|
| The notice says passwords were stored as hashes | The host login is not plaintext in the user table | A password in the screenshot still needs a hash crack |
| The image is unlisted and was never shared | The product page probably did not list it publicly | Someone without the ID can never assemble the direct link |
| You changed the host login password | That one login has been rotated | Database passwords and API keys in the screenshot are also dead |
| The host paused viewing for some images | Some IDs cannot fetch pixels for now | OCR text and historical metadata never left the store |
| You captured an error screen, not a password manager | You believe the frame has no password field | OCR cannot extract a token, connection string, or internal address |
| The operator invalidated session IDs | Current sessions on that host may no longer replay | X tokens, Google SSO links, and reused passwords are all safe |
Check the frame before upload, then the request
A slogan is not evidence. The next steps only check two things you control: whether the pixels about to leave this machine contain a canary, and whether a local tool’s request body should contain the original sentence at all. Do not send a real production password to any screenshot host to “verify” this.
- Prepare a disposable canary such as
canary-fp-20260920-gyazo-ocr. Type it in a blank note or a local HTML file and capture that. Do not mix in a real hostname or key. - Zoom the capture and check pixel by pixel: is the canary fully in frame, and is there a status-bar notification, another password field, or an old command in a terminal around it? Any word a person can read, OCR can store as text.
- If you still use a screenshot host: open DevTools Network, enable Preserve log, then upload. Search the request body for the canary. A host upload carries image bytes, so the canary enters the file. It does not enter the “password hash” column. That is the point: the hash does not cover this picture.
- Compare the other path. Open Burn-Link, write the same canary as text, and generate a link. Search Network again: the
POST /secretsbody should hold ciphertext, expiry, and a read count—not the original sentence, and not the key after the hash. The link shape iss.html?id={id}#{key}; the key sits only after#. RFC 9110 says the request-target URI does not include the fragment.
The first three steps show that, on the screenshot path, the secret leaves this machine as pixels—and as text the host may extract. The fourth shows that the same canary can take “AES-256-GCM on this device, ciphertext only uploaded.” Do not mix the two paths: do not capture into a host and then paste that direct link into a burn link, and do not capture the full burn URL and send that picture back to a host.
Do not send the full link and the ciphertext on the same channel. A screenshot host carries pixels. Burn-Link carries ciphertext plus a # key. If you capture the key into the same picture, or write the full s.html?id=…#… string into an image title, the protection after the hash is already gone for anyone who can see that image or that metadata row.
Three ways to over-read “the host is safe”
First, treat “unlisted” as access control. The UI not showing it only means the product did not put it on a public list. If the Image ID is in the store and the direct-link rule is public, an unshared image can still be assembled. “A list of private images was taken” in this notice is a counter-example to that reading, not a quirk unique to one vendor.
Second, treat a password change as rotation of secrets in the screenshot. The host login, the session ID, a third-party OAuth token, and a production key in the frame belong to different systems. The official request to change the Gyazo password and any reused password covers only the first few. If you captured a production console, you still have to revoke keys, rotate database accounts, and invalidate recovery codes on the original system. Local Password Audit can only match a public high-frequency weak-password list. It cannot prove a string never entered a host’s OCR table.
Third, treat “I captured an error, not a password” as a clean frame. A connection string in a terminal, a token= in the address bar, a verification code in a notification, or an inbox in the next window all enter the same picture. OCR does not filter by your intent. Before upload you can only inspect the one frame you will send, pixel by pixel. Naming the file error.png does not help.
FAQ
If the host stores passwords as hashes, are passwords in my screenshots safe too?
Those are different layers. A login password hash protects the account passphrase itself, and even that depends on the algorithm and whether it is salted. Once a screenshot is uploaded, the host can also store OCR text, Image IDs, upload IPs, and EXIF. Passwords, keys, and connection strings in the frame are often already searchable plaintext in the OCR column.
If a screenshot is unlisted and I never shared it, can only I open it?
Unlisted usually means the product UI did not put it on a public page. It does not mean nobody else can assemble the address. An Image ID is the information used to construct the image URL. Once that ID leaves with the metadata, an unlisted direct link is no longer protected by “you cannot guess it.” An operator pausing delivery only means some IDs cannot fetch pixels for now. It does not mean historical metadata was never copied.
If I change the host login password, do I still need to rotate secrets that appeared in screenshots?
Treat them as separate jobs. Changing the host password only cuts that one login, and it does not stop session IDs that already leaked. Database passwords, API keys, SSH private keys, and recovery codes that appeared in a screenshot must be rotated on the original system. Changing the host password does not replace that. If you reused the same or a similar password, change those too, as the operator asked.
Can I screenshot a one-time password and send it to a colleague?
Do not put a live password into a screenshot host or a chat photo album. Encrypt short text in this tab with AES-256-GCM and send it through Burn-Link, with the key after # in the URL. The shape is s.html?id={id}#{key}. Create and read are ready to use; no account. Material over 32 KB belongs in the File Encryption Box, one file up to 5 GB, output .lock / .enc. Do not treat a burn link as a drive.
Move the same canary onto a ready-to-use path
If you want a page that states the compute boundary in writing, open FastPwd Burn-Link. No signup. Paste the canary above, leave the read count at 1, generate, then compare Network as in the fourth step: the body should hold ciphertext, not the original sentence or the key after the hash. Use this path only when a short password must reach a colleague. Do not capture it first.
If the frame still has ticket text, a phone number, or an ID number, run rule-based redaction in the privacy cleaner before you decide to send anything. Cleaning happens on this device. Source text is not uploaded as business data and is not written to analytics. You can generate a random password first on the password generator, locally, length 6–128, default 16; shorter than 8 is flagged as weaker. Generation is not uploaded. If a whole screenshot file still has to leave, encrypt it in File Encryption Box first, then send the passphrase on a burn link by itself. Do not write it into a host title.
Before the next capture, keep three facts. First, the hash covers the host login, not the frame and not OCR. Second, an Image ID means an unlisted direct link is not access control. Third, the repeatable check is a pixel-by-pixel pass before upload, and a Network search for the canary when you switch to a ciphertext path. Those three sentences can go in a handoff note. “The host said passwords are hashed, so the screenshot is fine” cannot.
Further reading
Burn-after-read deletes ciphertext on the server. It does not prove the recipient skipped a screenshot: see Why a burn-after-read link can prove the server deleted the ciphertext, but cannot prove the recipient did not take a screenshot. A ZIP password before a drive upload does not hide filenames and is not local AES-GCM: see What a ZIP password blocks before a cloud upload, and why it is not local AES-GCM. “Local encryption, nothing uploaded” is not evidence until you search Network for a canary: see How to check if browser encryption never uploaded plaintext.