How CryptYak Works

CryptYak is a small, free toolkit for sending something private from one computer to another — or to a friend — without trusting anyone in the middle. The remote clipboard moves text between two of your machines using a five-character code. The encrypted chat opens a private link two people can use to swap messages, photos, video, and files. The vault lets you drop a file or note that the recipient can pick up later, with the whole thing wiping itself within a day.

Behind all three is the same idea: your browser does the scrambling, and I never get to see the unscrambled version. I can’t hand your data over, because I don’t have the readable version — not on disk, not in my logs, not in my backups. No accounts, no analytics, no third-party JavaScript. The site looks like a green-on-black terminal because that’s honest about what it is — a tool for moving bytes around, not a product trying to sell you something else.

Two of your computers share one private piece of text. You start one on your first machine, get a five-character code, and type the same code on your second. Whatever you save on one shows up on the other a moment later.

What happens when you save

Your computer scrambles the contents using a key it derives from your code. By the time the bundle reaches me, even I cannot read it — I just keep it for a while and hand it back when the other computer asks. The code is the only thing that turns the bundle back into readable text, and the code never leaves your devices.

The clipboard stays available for 24 hours and then disappears on its own. While the page is open you’ll see a countdown showing the time left; it turns amber for the last few minutes, and when it hits zero the contents wipe themselves on screen.

Why a five-character code

Five characters is enough to keep a stranger from guessing yours, and short enough to read aloud or type on a phone. The alphabet avoids the characters people confuse most often — no zero versus letter O, no one versus lowercase L, no five versus letter S — so a code you write down on paper still works the next morning.

Codes are not passwords. Anyone who has the code can read what you saved — that’s the point. Treat them like the password to a hotel safe you’ll empty in a day: convenient, short-lived, and never reused.

Reading aloud a chat or vault link

Chat rooms and vault drops give you long share links. If you’d rather read out a short code than spell out a URL on a phone call, the chat room and the sealed-vault screen each offer a one-click handoff: I tuck the URL into a fresh five-character clipboard for you. The other person types the five characters at the clipboard page, and their browser quietly opens the chat or the vault on their end. The handoff clipboard self-destructs after 24 hours like any other — the chat panel shows you the time remaining, and once it hits zero you can mint a fresh code without having to leave the room.

If you change your mind

When you generate a fresh code, there’s a small box you can tick that says “allow early destroy”. It’s off by default. With it on, two things happen: I remember the network you started from, and I hand you a separate destroy link to keep. Either is enough to wipe the clipboard immediately, before its 24-hour timer runs out. You can keep the destroy link to yourself, or paste it to anyone you trust to be able to clear the clipboard for you. Don’t post it publicly — whoever has it can wipe the clipboard.

If you don’t tick the box, the clipboard waits out its full 24 hours and you can’t cut it short.

Live updates while both windows are open

If you keep the clipboard open in two browser windows at once, saving in one nudges the other to refresh almost instantly. The nudge itself only carries your code — the actual content always travels through the same scramble-and-fetch round-trip and never appears on my server in readable form.

What it is not for

Great for moving short text between your own devices, or sharing a snippet with someone right next to you. Not a way to send a private message to a stranger — if they don’t already have the code, you have to give it to them somehow, and that channel needs to be safe in its own right.

When two of you open the same chat link, your computers shake hands directly and start sending messages and files between each other — they don’t go through me. You create a room, get a long random link, and share it with one person on a channel you trust. The room is two-seats only; a third opener can’t get in.

How the two computers find each other

Most home connections sit behind a router that gives every device a private address. Two private addresses can’t talk to each other directly without help meeting in the middle. A small public helper called a STUN server answers the question “what does my address look like from out on the public internet?” — and that’s it. Your two computers each ask, and then they have enough information to send packets to each other directly.

If your network is unusually strict (some workplaces and mobile carriers are), the helper alone isn’t enough and the connection needs a relay to get through. An optional relay can be used for that case — it only sees scrambled bytes and can’t read what you send any more than the rest of the internet can.

What stops anyone in the middle from reading your chat

Two layers of encryption protect every message and every file:

1. The browser-built layer. Modern browsers wrap the connection between two peers in encryption automatically. This is the same kind of encryption that protects banking websites, and it happens before I get involved.
2. A second layer of mine. As soon as the connection opens, your two computers privately agree on a fresh second key, just for this chat, using a math trick that lets them derive the same secret without ever sending the secret itself across the wire. Every message and every chunk of every file is then scrambled with that key.

Two layers means that if one ever turns out to have a flaw, the other is still doing its job. Belt and braces, deliberately.

What gets sent and what gets stored

I keep nothing about the chat — no transcript, no file copies, no record that the chat happened beyond what shows up briefly in normal connection logs. After the random link gets the right two browsers connected, all that flows is scrambled bytes between you, with no key on my server to read them.

Files travel the same way: your peer’s computer sends them in pieces, your browser decrypts each piece and reassembles the file into a download. The bytes never sit on my server.

What this is not

Not a group chat, not a place that remembers (refresh and the messages are gone for you), and not an identity check. Your peer is whoever opens the link — if it gets forwarded to someone you didn’t intend, they become your peer instead. Verify out of band before sending anything sensitive.

Leave a message or a file for someone — or for your future self — and have the whole thing self-destruct within a day. You drop the payload, I hand you back a single link, and you share it however you like.

What happens when you seal a drop

Your computer makes up a fresh secret just for this drop — random, brand new, never used again — and scrambles your message or file with that secret before anything leaves your browser. Only the scrambled bundle reaches my server.

You can also tape a short note onto the drop — a sentence or two of context for whoever opens it (“here’s the file you asked for, password is in our chat”). The note rides along inside the same scrambled bundle, scrambled with the same one-time secret, so I can’t read it either. When the recipient opens the link the note appears just above the payload; if you leave the note blank the recipient sees the payload alone, exactly as before.

I hand back a short identifier, and your browser stitches it together with the secret into a link that looks like this:

https://cryptyak.example/v/abc123…#xyz789…

That part after the # is the unlock secret. Browsers, by long-standing tradition, never send the part after the # to a server — it stays on your computer, and on the recipient’s when they open the link. I genuinely never see it.

Choosing how it disappears

When you create a drop you pick how long it stays available (up to 24 hours) and how many times it can be opened (once, a handful, or unlimited within the window). Whichever runs out first wipes the drop. A drop set to “1 read” is gone the moment the recipient opens it; either way, when it’s gone it’s gone — I don’t keep an archive.

The screen where you share the link — and the screen where the recipient opens it — both show a countdown of the time remaining. It turns amber when only a few minutes are left, and switches to a wiped-out empty state when zero arrives.

If you change your mind

There’s a small “allow early destroy” option in the settings panel. It’s off by default. With it on, you can wipe the drop immediately on the read page from the same browser you sealed it in — useful when you sent the link to the wrong person and want it gone before they read it. I also hand you a separate destroy link alongside the share link. Anyone with the destroy link can wipe the drop, so keep it private unless you specifically want to grant someone else the power to clear it for you.

If the box is unchecked, the drop runs out its timer and read budget on its own and nobody can cut it short.

Sharing a drop you can’t unscramble

The link is the entire credential. If you share only the part before the #, the recipient gets a polite “this link is incomplete” message. Forward the whole link — that’s the only thing the recipient needs.

Anyone who gets the full link can open the drop, subject to your read limit. The unlock secret will sit in the recipient’s browser history (and yours, if you previewed it) and may sync across their signed-in browser profiles — that’s the trade-off that lets them re-open it until it expires. If you’d rather the link be useless after one open, set the drop to “1 read.”

What it is not for

The vault is for delivering one thing to one person, or to your future self, with a built-in expiration date. It isn’t an inbox — I don’t notify the recipient. It isn’t a permanent store — everything self-destructs within a day. And it isn’t a way to bypass the trust you already have (or don’t) with whoever opens the link.

CryptYak protects what it can — the journey of your data from one of your computers, across the network, to another — but it cannot protect you from things that happen at the endpoints. Honest list of where I help and where I can’t.

What I don’t and can’t see

• The contents of your clipboard or vault drops — only scrambled bundles reach me.
• The five-character codes that unscramble clipboards. Those live on your devices.
• The decrypt keys for vault drops. Those live in the share link, in the part of the URL browsers don’t send to servers.
• Anything you send in a chat. Once your two computers connect, traffic flows directly between you.

Why I lock people out after a few wrong guesses

Five-character clipboard codes are short enough to type on a phone, which means they’re also short enough that someone could try one after another, hoping to land on an active clipboard. To make that uneconomic, I count failed attempts coming from the same internet address over a rolling day, and stop accepting new ones after a couple dozen. After that, the next try gets a polite “come back tomorrow.” The same lockout protects vault drops from someone trying to enumerate identifiers.

Two real situations are uncomfortable:

1. Shared internet addresses. If your office is all behind one outgoing address, one person mistyping codes a few dozen times can lock the rest of you out for a day. (The cap is generous enough that ordinary mistypes don’t add up there, but it’s worth knowing.)
2. It’s a day, not a few minutes. Once you trip it, you’re out until tomorrow. If you mistype, take a breath; if you’ve already used up your budget, switch to mobile data or a different network and you’ll have a fresh one.

Per-link viewer limit

Clipboards and vault drops are meant for personal sharing. To stop someone posting a link in a public forum and turning the site into a free file host, each clipboard or vault link is limited to a generous-but-bounded number of distinct viewers. People who already opened the link keep their access for the rest of the day; new networks past the cap get a friendly “the pasture is full” message and need to ask the original sender for a new one. Your network shows up as the same viewer every time, so re-opening a link you’ve already seen is always free.

What CryptYak cannot protect against

• Software on your own device. If something nasty is running on your computer or your peer’s, it can read what you type before I ever see it scrambled. Keep your devices clean.
• Looking over your shoulder. Anyone who can see your screen can read your clipboard or chat regardless of how the bytes travel.
• The person you share the code, link, or room with. If you give them your code or link, you’re trusting them. I have no way to verify the person on the other end is who you think it is — that’s on you, agreed out loud or out-of-band.
• Traffic patterns. I can see when a request happens and which clipboard code or vault identifier it’s for — not what is in it, but the metadata that something exists. I log as little of this as possible.
• Browser bugs. Everything I do leans on the browser’s built-in scramble-and-unscramble machinery. If a future flaw is found there, the day it’s found is the day to update your browser.
• Strict networks. A handful of unusually strict corporate or carrier networks won’t let two computers find each other through the public helper, so a chat connection can’t be made. That isn’t a privacy failure — nothing leaks — but it is a usability failure for those users. Operators can plug in a relay to cover that case.

What I promise instead

• I never sell or share what little I can see.
• I never run analytics or third-party JavaScript — the page you load is exactly the page I serve.
• I am transparent about how it works. The cryptography is standard and the page you are reading lists the limits up front.