gcopy syncs a clipboard across devices through a browser

A web app is the client, which is the whole trick

gcopy is a clipboard synchronisation service between different operating systems, and it supports text, screenshots and files. The design decision that makes it usable is that the client is a web page rather than an application. The usage description is three steps. You open the site on two devices, A and B, in a browser and log in with the same token. On device A you copy something, for example with Ctrl+C, and press the button on the right side of the page. Then you switch to device B, press the button again and the data is synchronised, and you can paste with Ctrl+V. Nothing is installed on either machine. The author explains why in the background section, and the history is worth reading because it shows the dead ends. The first version used Git as the backend storage with PowerShell and osascript scripts to move clipboard contents, which worked but was not user friendly for non technical users. Replacing Git with a Go service as the data transfer backend fixed that but still required users to download and run a GCopy client on each device. The current version exists to remove that barrier.

An eight character token is the only authentication

Users authenticate with an 8-character token, which is used as the shared clipboard key across devices. That single sentence describes the entire access control model, and it is worth sitting with before deploying it anywhere sensitive. The token is not a user account with a password, a session or a scope. It is a bearer secret that both proves who you are and names the shared clipboard, so anyone who obtains it can both read what you copy and write into your clipboard. There is no per-user separation in the design, because the token is the unit of sharing. For the use case the project describes, a developer moving text between their own two machines, that is a reasonable trade, since the token never leaves your devices and the alternative tools charge money or require a shared local network. For anything else, it is a thin boundary, and the self hosting path becomes the interesting one because you can then control where the data goes. The data handling policy is stated just as plainly. GCopy does not persistently store your data, it is all kept in memory, and if you are inactive for 24h the data will expire.

Files go through upload and download, not the clipboard

The limitations section explains why the feature set is shaped the way it is. Due to browser limitations, reading and setting files directly in the clipboard are not supported, so file synchronisation is achieved through uploading and downloading, which the project describes as ensuring a smooth user experience. That is the real reason a file transfer works where a clipboard file write does not, and it has consequences. At any given time, only one file can be synchronised, so a second file replaces the first rather than joining it. And due to limited server memory, the size of the files you synchronise must not exceed the max content length setting, in megabytes. That second limit is a direct consequence of the in-memory design that gives the service its privacy property. A server that holds payloads in RAM to avoid writing them to disk will exhaust that memory before it fills a disk, so the ceiling on a file is set by the instance size. For a self hosted deployment the fix is to size the machine to the files you expect, and the max content length option is the knob to set.

Clipboard API support is the real compatibility matrix

GCopy depends on the browser's Clipboard API, and the documentation points at the browser compatibility table on the developer.mozilla.org site for the details. The tested browsers are listed in a table, and the spread is instructive. Chrome for Android at 107.0.5304.105, Chrome for macOS at 121.0.6167.85, Chrome for Windows at 123.0.6312.86, Edge for Android at 108.0.1462.48, Edge for HarmonyOS 3.0 and 4.0 at 122.0.2365.99, Edge for Linux at 130.0.2849.52, Edge for Windows 10 at 124.0.2478.80, Opera for macOS and for Windows 10 at Opera One 109.0.5097.68, Safari at 15.6.1 and Safari for iOS at 16.1, all marked as tested. The interesting inclusion is Edge for HarmonyOS, which is a sign the author actually runs this on more than a developer workstation. The practical point for a reader is that the browser requirement is not a formality, since the whole flow of copy, press, paste depends on the Clipboard API being present and permitted, and permissions for clipboard access are granted per origin and can be revoked by the user.

A Go server with a vendored frontend and a Docker image

The implementation is a Go service with a frontend built separately and embedded. The go.mod declares the module github.com/llaoj/gcopy with go 1.21, and the direct dependencies are small and specific. gin serves the HTTP layer, gorilla/sessions handles sessions, mileusna/useragent parses the user agent string, and sirupsen/logrus does the logging. Everything else in the manifest is an indirect dependency of those four, which is a sign of a deliberately thin dependency surface, and the repository vendors its dependencies with a vendor/ directory and a gomod target that runs go mod tidy, go mod vendor and go mod verify. The Makefile shows the build layout. The frontend is built with npm ci and npm run build into a static directory that Go then embeds, and the binary is cross compiled for linux, amd64 and arm64 plus the two Darwin targets with CGO disabled, with the version stamped into the binary through ldflags. The container image is published for linux/amd64 and linux/arm64 with buildx, and the version number is read from a version.txt file at the root. The primary language listed for the repository is TypeScript, which is the frontend, and the tree shows a frontend/ directory, internal/, pkg/, cmd/ and a scripts/ directory.

Self hosting is the answer to the privacy question

The project runs a hosted instance at gcopy.llaoj.cn, and the quick start section tells you to visit it to experience the service directly. Alongside that there are two deployment guides, one for Docker using the official container image and one from source covering a build from source or a downloaded release binary. Given the authentication model and the in-memory data policy, self hosting is the sensible default for anyone whose clipboard carries anything sensitive. The hosting model is also the reason for the sponsor section, since GCopy requires cloud server resources to keep the online service running, and the project asks for a GitHub star or a donation. There is a project documentation site, a Chinese version of the README under docs/zh-CN, a Discord server for discussion, and a personal email address for support, and the CHANGELOG and version history show a steady line of releases through v1.5.5, v1.6.0 and v2.0.2. The repository is not archived and the last push was on 2026-10-19, so the service is actively maintained.

Editorial conclusion

Adopt gcopy when you routinely move between a Windows PC, a Mac and mobile devices and want one shared clipboard for text, screenshots and files without installing a client on every machine. Do not adopt it when your workflow needs several files synchronised at once, or when clipboard data must persist beyond a day, since the service keeps data in memory and expires it after 24 hours of inactivity. Verify first that your browsers support the Clipboard API, that you can self host the service if you do not want your data on a third party host, and that the max content length setting is large enough for the files you intend to move.

Frequently asked questions

Official sources

1. License: MIT
2. llaoj/gcopy on GitHub
3. Project website
4. README
5. Releases