Paste text on Device A. Enter a 4-digit code on Device B. Text appears instantly. But what actually happens in between? This guide explains the full technical picture — in plain language.
An online clipboard is a small, real-time web application that uses a cloud database as a temporary bridge between two browsers. When you paste text and generate a code, that text is written to a database entry keyed by the code. When someone enters the same code on any device, they read from that same database entry.
The "magic" is mostly the simplicity: there's no complex protocol, no P2P connection negotiation, no app pairing. Both devices just talk to the same database row. One writes. One reads. The database entry then auto-deletes itself.
Online Clipboard is built with three main technologies:
The user interface is a single-page React application built with Vite. It runs entirely in your browser — no page reloads. React handles the UI state (showing the code, the countdown timer, the QR modal), while Vite bundles and serves the app from Firebase Hosting.
The clip text is stored in Firebase RTDB, a cloud-hosted JSON database that supports real-time sync via WebSockets. Instead of a traditional REST API (request-response), Firebase keeps a persistent connection open — so changes appear instantly without polling.
A server-side JavaScript function runs on Google's infrastructure on a regular schedule. It finds all clips older than 5 minutes and deletes them. This is how auto-deletion is enforced — it happens even if you close your browser.
The React app reads the textarea value and prepares a write operation.
A random number between 1000 and 9999 is generated using a pseudo-random algorithm seeded with the current timestamp.
Firebase RTDB is queried for /clips/{code}. If it exists (a collision), a new code is generated and the check repeats.
The SDK writes a JSON object: { text: "...", createdAt: timestamp, mode: "normal" } to the path /clips/{code}.
The UI transitions to "result" mode, displaying the 4-digit code, share link, QR code button, and a 5-minute countdown timer running locally in the browser.
The entire process from "Generate Code" click to code display takes under 500 milliseconds on a normal internet connection — most of which is the network roundtrip to Firebase.
The four digit inputs are concatenated to form the code string.
/clips/{code}
The Firebase SDK sends a request over the existing WebSocket connection. The database responds with the clip object or null.
The clip text is rendered in the result card. The remaining time is calculated from the stored createdAt timestamp.
Either the code is wrong, the clip expired, or the clip was never created. No specific information is given to prevent enumeration probing.
Retrieval is a read-once operation — the clip is not deleted when it's retrieved. This allows you to share the same code or link with multiple people. The clip only disappears at the 5-minute server-side deletion.
There are many database options available to web developers. Firebase RTDB was chosen for specific reasons that fit this use case well.
Firebase is a "Backend-as-a-Service" — you write no server code to handle reads and writes. The Firebase SDK in the browser communicates directly with Firebase's infrastructure. This removes an entire layer of complexity and failure points.
Firebase RTDB keeps a persistent WebSocket connection open. Writes are immediately visible to all readers watching the same path. In the future, this means multi-device live sync features could be added trivially.
Firebase's security rules language lets you define who can read and write each path. Online Clipboard's rules allow:
// Firebase security rules for /clips { "rules": { "clips": { "$code": { ".read": true, ".write": "(!data.exists() && newData.exists()) || (data.exists() && !newData.exists())" } } } }
This rule means: you can write to /clips/4821 only if it's currently empty (creating a new clip), or if you're deleting an existing clip (the Cloud Function cleanup). You cannot overwrite a clip in progress.
The code generation has to balance several constraints:
A pseudo-random integer between 1000 and 9999 is generated. The code space has 9,000 possible values. The app checks if the generated code is already in use in Firebase. If it is (a collision), a new code is generated and checked again. This retry loop runs until a free code is found, which on a lightly-loaded system takes one attempt almost always.
function generateCode() { return Math.floor(Math.random() * 9000) + 1000; } async function getUniqueCode() { let code, exists; do { code = generateCode(); // Check Firebase: does /clips/{code} exist? exists = await checkCodeExists(code); } while (exists); return code; }
With 9,000 possible codes and typical usage, fewer than 100 clips exist simultaneously. The probability of generating a colliding code is roughly 100/9000 ≈ 1.1%. In practice, the retry is needed very rarely and adds negligible delay.
The 5-minute clip expiry is not enforced by the browser — it's enforced server-side by a Firebase Cloud Function. This is critical because: (1) users might close their browser, (2) the countdown timer is just a display — it cannot actually delete data, (3) server-side enforcement guarantees deletion regardless of client behavior.
Firebase Cloud Functions are JavaScript functions that run on Google's servers. They're triggered by events (database writes, HTTP requests, or schedules). Online Clipboard uses a scheduled function — it runs automatically every few minutes.
// Simplified version of the cleanup function exports.cleanupExpiredClips = functions.pubsub .schedule('every 5 minutes') .onRun(async (context) => { const db = admin.database(); const cutoff = Date.now() - 5 * 60 * 1000; // 5 min ago const snapshot = await db.ref('clips') .orderByChild('createdAt') .endAt(cutoff) .once('value'); const updates = {}; snapshot.forEach(child => { updates[child.key] = null; // null = delete in RTDB }); if (Object.keys(updates).length > 0) { await db.ref('clips').update(updates); } });
In Firebase RTDB, setting a value to null is equivalent to deleting it. The cleanup function sets all expired clip entries to null in a single batch operation.
The QR Code button opens a modal that shows a scannable QR code. The QR code encodes the share URL (https://online-clipboard.tech/4821). When you scan this with any phone camera, it opens the URL in the phone's default browser, which automatically retrieves the clip.
QR codes are generated entirely in the browser using the qrcode.react library. The library takes the URL string and converts it to an SVG with black/white modules (the square dots). No server request is made to generate the QR code — it's pure client-side math.
The QR module uses Reed-Solomon error correction at level "M" (medium), which means the QR can be read even if up to 15% of it is obscured or damaged. The size is set to 220×220 px, which is the minimum comfortable scannable size on a laptop screen.
Switching to "Coder Mode" changes the UI and the stored data slightly, but the underlying mechanism — write to Firebase, read with a code — is identical.
mode: "coder" field is saved in the Firebase record so the receiving device shows the correct UI mode.Currently, no — retrieval is a one-time read, not a live subscription. If you retrieve a clip and it's updated (it can't be — clips are immutable after creation), you wouldn't see the update automatically. Clips are write-once, then read-many, then deleted.
Four digits is the sweet spot between usability and collision probability. Four digits are easy to read across a room, fast to type on mobile, and memorable for 5 minutes. With typical usage loads, 9,000 possible codes provides low collision rates. Six digits would reduce collisions but make the tool less usable for its primary purpose.
Clips would remain in the database past the 5-minute window. Firebase Cloud Functions are highly reliable infrastructure, but no system is perfect. If the function misses a run, it catches up on the next execution and deletes all overdue clips at once.
No. Text is stored as-is in Firebase. For the character limits involved (up to 5,000 characters ≈ 5KB), compression overhead would exceed the size savings.
Approximately. The countdown is calculated from the createdAt timestamp stored in the clip. If there's clock skew between your device and Firebase servers, the displayed time may be off by a few seconds. The server-side cleanup is the authoritative expiry — the timer is informational.
Yes. The core is: Firebase RTDB + a simple React frontend + a scheduled Cloud Function for cleanup. The hardest parts are the security rules, the code collision logic, and the URL-based auto-retrieve feature. A minimal version could be built in a weekend.
Paste text, get a code, retrieve on any device — 5 minutes, then gone forever.
Open Online Clipboard →