# DropPoint: a small Electron window that parks your files on top of everything else

> DropPoint is an Electron utility for Windows, macOS and Linux that lets you drop files into a floating window and drag them out somewhere else, including across virtual desktops. It is a thin, single-purpose tool with a playwright test suite, but its newest tagged release is from 2022 while the package version has moved to 1.3.1.

**GameGodS3/DropPoint** — Make drag-and-drop easier using DropPoint. Drag content without having to open side-by-side windows

- Repository: https://github.com/GameGodS3/DropPoint
- Website: https://droppoint.netlify.app/
- Stars: 1,099 · Forks: 70
- Language: JavaScript
- License: GPL-3.0
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/gamegods3-droppoint

## A parking space for the file in transit

DropPoint exists to remove one specific annoyance: dragging content between two windows you cannot see at the same time. The description says it plainly, Drag content without having to open side-by-side windows, and the mechanism is small enough to describe in one sentence. You drag files or folders from the system into the DropPoint window, go to your destination, and drag them out.

That is a deliberately narrow product. It is not a file manager, not a transfer tool, and not a replacement for the clipboard. It is a surface that holds a payload while you move between locations.

The demo section shows the two cases that matter. One clip is dragging between maximized windows in the same desktop. The other is dragging between windows in different virtual desktops or workspaces, which is the case that no ordinary drag can solve at all.

That second case is the reason the app exists rather than the first. Dragging between two visible windows is something every operating system does already. Dragging into a window that is on another virtual desktop is impossible without a holding area, and that is what DropPoint provides.

On Windows the holding area is not automatic, and the documentation explains the extra step. To enable stickyness across virtual desktops you go to Task view while DropPoint is running, right click it and tick Show Window from this app on all Desktops. Stickyness in other operating systems works by default, which is a small but telling asymmetry between the platforms.

## A tray resident window, and a keyboard shortcut that spawns it anywhere

The usage section is three bullets, and one of them is the one people will actually use.

Drag and drop any files or folders from the system into DropPoint, go to your desired location and drag it out. That is the core loop.

The second bullet is window management. The app minimises to tray by default when you close the instance. To open the instance, you click on the system tray, and to quit you right click on the tray icon and choose Quit.

The third bullet is the good one. While DropPoint is in the system tray, pressing Shift plus Caps Lock anywhere on the system creates a new instance of DropPoint at the mouse location. The documentation notes this was tested on Windows and Linux, and that on macOS the shortcut is Shift plus Tab.

That behaviour is what makes the tool feel native rather than like a utility you have to find. The window does not exist until you summon it, it appears under the cursor, you drop the file in, and it disappears again. A persistent floating window would be in the way, and a window you had to click from a taskbar would defeat the purpose.

The Shift plus Caps Lock combination is a deliberate choice of a rarely used chord, and it is also a choice that can conflict with keyboard layouts and with other software that reads the same keys. The macOS variant uses Shift plus Tab, which is closer to a system shortcut and therefore more likely to collide.

## Build targets, from an AppImage to an NSIS installer

The distribution story is the package format, and the list is longer than you would expect from an app this small.

For Windows there is a zip you extract to a blank folder and run DropPoint.exe from, and the electron-builder configuration also lists nsis as a Windows target. For macOS there are two disk images, one for Intel and one for Apple Silicon for M1 devices only, and after installing you open System Preferences, Security and Privacy, and choose Open Anyway, which is the standard gatekeeper override for an unnotarised app. For Linux there is an AppImage that runs on all distributions, a .deb for Debian based systems such as Ubuntu, Mint and Pop OS, a .tar.gz for Arch based systems, and an .rpm for RHEL based systems such as Fedora and Red Hat.

The package.json confirms the target list. Linux is configured for AppImage, deb, tar.gz and rpm with the Utility category, Windows for zip and nsis, and macOS with the public.app-category.utilities category and the dmg icon disabled.

The runtime dependencies are equally small, which is the interesting engineering decision here. electron-store handles settings persistence, electron-updater handles updates, and preline is a CSS framework for the interface. Everything else is a dev dependency: electron itself, electron-builder for packaging, tailwindcss with the forms plugin for styling, and Playwright for the tests.

An application with three runtime dependencies and one window is about as small as an Electron project can usefully be, and the packaging breadth is what tells you the author cared more about people being able to install it than about the app doing more.

## Building from source, and the Node version trap

The developer installation path is short, and it comes with the most useful warning in the whole README.

You need Node.js and Git installed. Then clone and change into the directory.

```bash
git clone https://github.com/GameGodS3/DropPoint.git
cd DropPoint
```

Then install dependencies and run.

```bash
npm install
npm start
```

The warning is about the Node version. The documentation says to use Node.js 22 LTS, described as the version the project is built and tested against, with a pointer to the .nvmrc file. Newer non-LTS Current releases such as Node 26 have ESM module resolution regressions that break the Electron binary install, where @electron/get fails to load sumchecker. If you use nvm, run nvm use.

That is a specific, reproducible failure rather than a general warning, and it is worth respecting exactly. The package.json engines field asks for Node >=22.12.0, and the repository does carry an .nvmrc file, so the intended version is pinned in two places. The npm start script runs electron ., and the other scripts are electron-builder with --publish never for a local build and --publish always for a release, plus playwright test.

The reason this is worth mentioning is the general shape of Electron development. The runtime version of Node you develop against is not the version that ships to users, and the failure happens in the installer step rather than in your own code, which is exactly the kind of thing that costs an afternoon if you are not warned.

## Playwright as the test layer for a window that has no logic

The test script is playwright test, and the repository carries a playwright.config.js alongside a test/ directory. The test dependency is @playwright/test at 1.61.1.

That choice is interesting for an application whose entire feature is a drag and drop. There is almost no logic to unit test here. What needs testing is behaviour: does a file dropped on the window land in it, does dragging it out produce the right file, does the tray behaviour work, does the shortcut spawn a window at the cursor.

Those are end to end interactions with a real Electron window, which is exactly what Playwright is for. A unit test of a function that copies a path would tell you very little about whether the application works.

It also means the tests are the slowest and most fragile part of the build, since they drive an actual window on an actual desktop. A CI runner without a display needs a virtual one, and the electron-builder configuration and the playwright configuration have to agree about which platform is being tested.

The repository also carries .deepsource.toml, which is a static analysis configuration, so the JavaScript is checked by something beyond the linter. Combined with the playwright suite, that gives a codebase with two independent checks on it, which is more than many utilities of this size have.

The build workflow badge in the README points at a Build workflow, and the credits section thanks a specific contributor for CI/CD and Releases, which suggests the automation is a cared about part of the project rather than an afterthought.

## The version gap, and the licensing of the result

The release list and the package version do not match, and for a project distributed as installers rather than as a package, that mismatch has a specific meaning.

The tagged releases listed are v1.2.1 from 2022-09-12, v1.2.0 from 2022-07-25 and v1.1.3 from 2021-10-02. The package.json says version 1.3.1. The last push was on 2026-08-04, and the repository is not archived.

So the code is moving and the tags lag. For a user who installs from the Releases page, the newest tagged build is the newest installer, and the 1.3.x line referenced in the minimum OS requirements section may or may not be what you get. The documentation hedges by saying older releases, pre-1.3.x, are available on the Releases Page for legacy systems, which implies 1.3.x builds exist there too even though the release list here is stale.

If you are evaluating this as a dependency rather than as an application, that is the important detail. There is no npm package to add, no version constraint to write, no lockfile to commit. The Electron app is the deliverable, so a version pin is not available to you, and the update behaviour is whatever electron-updater does.

The licence is GPL-3.0-or-later, declared in package.json and in the LICENSE file at the root. For a personal utility that is a non-issue. For anyone who wants to fork it into a product, the copyleft terms are the thing to read, and the fact that the licence is or-later gives you the option to take a later version.

The repository also links a Buy Me a Coffee button, so the project takes donations.

## Conclusion

DropPoint fits anyone who regularly moves a file between two windows that cannot both be on screen, particularly on a multi monitor setup or when working across virtual desktops, and it fits people who want a small dedicated surface for the file in transit rather than juggling a file manager. It does not fit a team that needs an auditable, reproducible build, because the shipped installers are the distribution channel and there is no package to pin, and it does not fit a user on a platform outside the three it targets. Check three things before you rely on it. Check the release you download, since the newest tagged release listed is v1.2.1 from 2022-09-12 while the package version in the repository is 1.3.1 and the last push was on 2026-08-04, so the tags and the current code are not the same thing. Check your operating system version, because the minimum is Windows 10 or later, macOS 12 Monterey or later and a modern 64 bit Linux distribution, with older pre-1.3.x builds on the Releases page for legacy systems. And check the Node version if you build from source, because the project is built and tested against Node.js 22 LTS and the documentation says newer non-LTS releases such as Node 26 have module resolution regressions that break the Electron binary install. The license is GPL-3.0-or-later.

## FAQ

### What does DropPoint do and which platforms does it support?

DropPoint lets you drag files or folders into a floating window and drag them out later, so you do not need side-by-side windows. It works on Windows, macOS and Linux, with minimum versions of Windows 10 or later, macOS 12 Monterey or later and a modern 64 bit Linux distribution.

### How do I install DropPoint on Linux?

Download the AppImage to run on any distribution, or pick the package for your family: droppoint_1.x.x_amd64.deb for Debian based systems, droppoint-1.x.x.tar.gz for Arch based systems, or droppoint-1.x.x.x86_64.rpm for RHEL based systems.

### How do I make the DropPoint window stick across virtual desktops on Windows?

While DropPoint is running, go to Task view, right click the app and tick Show Window from this app on all Desktops. Stickyness in other operating systems works by default.

### How do I run DropPoint from source?

Clone the repository, change into the directory, then run npm install and npm start, with the start script running electron. Use Node.js 22 LTS, the version the project is built and tested against, since newer non-LTS releases such as Node 26 break the Electron binary install.

### How is DropPoint tested?

The test script is playwright test, with the Playwright configuration in playwright.config.js and the tests in a test directory. The repository also carries a .deepsource.toml for static analysis, and the electron-builder configuration and playwright configuration have to agree on the platform under test.

### What license is DropPoint released under?

GPL-3.0-or-later, declared in package.json with the LICENSE file at the root of the repository. The package version is 1.3.1, the newest listed tagged release is v1.2.1 from 2022-09-12, and the last push was on 2026-08-04.

## Sources

- [GameGodS3/DropPoint on GitHub](https://github.com/GameGodS3/DropPoint)
- [License: GPL-3.0](https://github.com/GameGodS3/DropPoint/blob/main/LICENSE)
- [Project website](https://droppoint.netlify.app/)
- [README](https://github.com/GameGodS3/DropPoint/blob/main/README.md)
- [Releases](https://github.com/GameGodS3/DropPoint/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/gamegods3-droppoint