# DragSelect: a dependency free selection and drag and drop library

> DragSelect adds a rubber band selection algorithm to a web application, with drag and drop, keyboard control, modifier keys for multiple independent selections, touch support, and SVG handling, in a single library with no dependencies. The author built it because nothing else did the job without jQuery, and the project is used in file managers and large hosting consoles.

**ThibaultJanBeyer/DragSelect** — An easy JavaScript library for selecting and moving elements. With no dependencies. Drag-Select & Drag-And-Drop. – Examples:

- Repository: https://github.com/ThibaultJanBeyer/DragSelect
- Website: https://dragselect.com/
- Stars: 768 · Forks: 81
- Language: HTML
- License: NOASSERTION
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/thibaultjanbeyer-dragselect

## A selection algorithm, not a widget

DragSelect is a JavaScript library for selecting and moving elements, with no dependencies, covering both drag select and drag and drop. The one line summary in the README is that it easily adds a selection algorithm to your application or website, and the project description repeats it with the emphasis on there being no dependencies.

The distinction from a component library is worth holding on to, because it explains the whole design. A component library gives you a widget with its own markup, its own styling, and its own opinions about the DOM. DragSelect gives you an algorithm: you tell it which elements are selectable, and it manages the selection state, the rubber band, and the pointer handling, and it tells you what happened through callbacks.

That is why the key features list is written in terms of behaviour rather than appearance. It replicates operating system drag selection in the browser, so the interaction feels like selecting files in a file manager rather than like using a web widget. It uses modifier keys to make multiple independent selections, so a user can select two disjoint groups and act on both. It supports select, drag, and drop via the keyboard, and accessibility is a listed feature rather than an afterthought. It supports SVG, which matters because SVG elements do not behave like HTML elements in a selection rectangle, and it supports mobile through touch interaction.

Two more claims are worth quoting carefully, because they are the ones a user will notice. It is written with performance in mind, and can easily select more than fifteen thousand elements. And it is lightweight, with the size shown in the badges as a gzipped figure for the minified build served from the project site.

The project is MIT licensed in the repository metadata, it is not archived, the last push was on 2026-10-05, and the releases are v3.1.4 from 2026-10-03, v3.1.2 from 2025-10-24, and v3.1.1 from 2024-10-26. The site is dragselect.com, and the documentation is being migrated there from the older pages, with the README pointing at the introduction page as the most up to date source.

## Why it was written at all

The Why section of the README is short and blunt, and it is the best explanation of the design constraints.

The reason given is that apparently there was nothing that does not require jQuery out there. The comparison drawn is with the jQuery UI selectable and draggable plugins, and the claim is that this is better and has no dependencies.

That is the whole origin story, and it is a common one for a focused utility library. The jQuery UI plugins were the standard answer for selection and drag and drop for years, and they dragged a framework into every project that used them. When the browser stopped needing jQuery for anything else, those plugins became the heaviest dependency in an otherwise small bundle.

The second half of the section gives the real world evidence, and it is more convincing than the feature list. The library is used in multiple professional rich interface applications, and the example given is a file management system where the user selects files to organise them and change their metadata, and with the plugin those users can select multiple files and perform batch operations, applying changes to several at once.

The second example is a huge graphical cloud hosting manager with millions of active users, where users select multiple servers and storages on an art board to perform multi-operations, re-organise them, move them in the interface, or batch delete them. The author says they have been running it since January and that it is helpful and very stable.

Both examples are the same shape of problem, and it is a shape that most interfaces never need. A selection rectangle is trivial for five items and genuinely hard for five thousand, and the cases where it matters are the ones where the user is doing a bulk operation on a large collection.

## The interface: settings, callbacks, methods, and CSS classes

The table of contents in the README lists the shape of the API, and it is the shape you would expect from a library that separates algorithm from presentation.

There is a section on the constructor properties, which the README calls settings. There is a section on event callbacks, which is how the library reports selection changes, drags, and drops. There is a section on methods, which is the imperative side of the API. And there is a section on CSS classes, which is how the library lets you style the selection rectangle and the selected elements without shipping a stylesheet.

The CSS class approach is the piece that makes the library fit an existing design system. A library that draws its own selection rectangle in a fixed style is a library you have to override with CSS hacks. A library that exposes class names on the selection element and on the selected items gives you a hook to style the selection the way your application styles everything else.

The accessibility claim in the feature list is backed by two separate entries, and they are different things. Select, drag, and drop also via keyboard is a keyboard-operable selection, where a user can move a focus through the elements and add to the selection with the keyboard rather than with a pointer. Accessibility as a feature is the broader claim that a screen reader user can work with the same interface.

The combination of those two entries with the modifier key support is the interesting part of the design, because it is what makes the library usable in a professional interface rather than a demo. A user who needs multiple disjoint selections holds a modifier key, which is the same gesture the operating system uses, and a user who cannot use a pointer at all gets a keyboard path to the same operations.

## A workspace with the library, the docs site, and a build script

The repository layout shows how the project is put together, and it is a monorepo with two workspaces.

```json
  "scripts": {
    "initial": "cd ./DragSelect && yarn && cd ../www && yarn && cd ..",
    "initial:ci": "cd ./DragSelect && yarn install --frozen-lockfile && cd ../www && yarn install --frozen-lockfile && cd ..",
    "start": "cd ./DragSelect && yarn start",
    "test": "cd ./DragSelect && yarn test",
    "build:docs": "cd www && yarn && yarn build && cd ..",
    "build:dragselect": "cd ./DragSelect && yarn build -- --ci && cd ..",
    "build": "yarn build:dragselect && yarn build:docs && node ./build.js && yarn test"
  },
```

The two workspaces are the DragSelect directory, which is the library itself, and the www directory, which is the documentation site. The root manifest is marked private, and the build script at the top level assembles the artefacts.

Two details in the scripts are worth a moment. The initial and initial:ci scripts differ only in the install flags, with the continuous integration variant using a frozen lockfile, which is the standard way of keeping a build reproducible. And the top level build runs the library build, then the documentation build, then a node script that appears to assemble the distribution, and then the tests. Running the tests as the last step of the build means a broken test fails the build rather than shipping.

The rest of the repository is a normal project: a changelog, a code of conduct, a contributing guide, a deployment document, the licence file, the continuous integration directory, and the source of the library under the DragSelect workspace with its own package manifest.

## Licensing, funding, and who maintains it

Two aspects of this project are unusual enough to check before you depend on it, and both are visible in the repository rather than buried.

The first is the licence, and it is genuinely ambiguous from the outside. The package manifest in the repository declares the licence as GPLv3, while the repository metadata classifies it as a custom licence that GitHub cannot classify automatically, and the project site links a separate licences page. The README does not restate the terms.

That combination usually means there is more than one licence in play, perhaps one for the library and another for something else in the repository, but the README does not say, and the authoritative text is the licences page on the project site and the licence file in the repository. For a library that is distributed on npm and embedded in other people's applications, a copyleft licence is a real constraint on how you can ship it, and this is the one thing to read before you use it.

The second is funding, and the README is unusually direct about it. It asks for donations to support the countless hours of hard work and support, and points out that if your company makes money then there is no excuse. For anyone who is too poor to donate, the alternative offered is contributing code.

The commercial supporters are named, and both are testing services. TestMu AI, previously LambdaTest, supports the project with a free account and a donation, and BrowserStack does the same. Both are cross browser testing services, which is a sensible fit for a library that claims to work in all major browsers and has to be tested against them continuously.

The donation link is a Bitcoin address, with the note that donations are distributed with all project contributors proportionally to their involvement, and a comment about how many more downloads there would be if everyone had donated a single unit of currency.

## Conclusion

DragSelect fits a team building an artboard, a file manager, or a console where the user selects many items and acts on them in bulk, and who does not want to pull in a UI framework or a jQuery plugin for one interaction. It does not fit a project that needs a maintained, semver-pinned dependency on a fast moving basis, because the release history shows long gaps, and it does not fit a team that needs a permissive licence, since the manifest declares GPLv3. Verify first that the licence terms suit your distribution, since the package manifest and the repository classification do not match cleanly, that the interaction model fits your existing pointer handling, and that the version you pick has the accessibility behaviour you need, because the keyboard and screen reader support is a stated feature rather than an afterthought.

## FAQ

### What does DragSelect do?

It is a JavaScript library for selecting and moving elements with no dependencies, covering both rubber band drag selection and drag and drop. It replicates operating system drag selection in the browser, supports modifier keys for multiple independent selections, works with the keyboard, supports SVG and touch interaction, and is written with performance in mind for selecting large numbers of elements.

### Why was DragSelect written?

Because the author found that nothing did the job without jQuery, and the alternatives were the jQuery UI selectable and draggable plugins. The library is used in production for bulk operations, such as selecting files in a file management system or many servers on an art board in a hosting console.

### Does DragSelect have any dependencies?

No. The key features list and the repository badges both state that it has no dependencies, and the package manifest in the DragSelect workspace is the one with the dependencies-none badge. The project ships a small minified build and a gzipped size figure for it.

### How do I style the DragSelect selection rectangle?

Through the CSS classes section of the API, which is how the library lets you style the selection and the selected elements rather than shipping a fixed style you have to override. The API is also split into constructor properties, event callbacks, and methods.

### What licence is DragSelect released under?

The package manifest in the repository declares the licence as GPLv3, while the repository is classified as having a custom licence that GitHub cannot classify, and the project site links a dedicated licences page. The licence file in the repository and the licences page are the authoritative terms to read before shipping it.

## Sources

- [Issues](https://github.com/ThibaultJanBeyer/DragSelect/issues)
- [Project website](https://dragselect.com/)
- [README](https://github.com/ThibaultJanBeyer/DragSelect/blob/main/README.md)
- [Releases](https://github.com/ThibaultJanBeyer/DragSelect/releases)
- [ThibaultJanBeyer/DragSelect on GitHub](https://github.com/ThibaultJanBeyer/DragSelect)

---

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