easings.net: A Cheat Sheet for Choosing Easing Functions

What easings.net Is Actually For

The README opens with the project's own one-line description: "Simple cheat sheet to help developers pick the right easing function." That sentence is the whole scope. The repository is the source of the easings.net site, a reference page where you look up a timing curve, compare it against its neighbours, and copy the curve you want into your own animation code.

The audience is narrow on purpose. If you already know you want an ease-out and you know which flavour, you do not need this. It is for the moment when you have a transition that feels wrong and you cannot say why, and you want to see the difference between cubic-bezier values side by side instead of guessing. Designers who hand timing curves to engineers are the other obvious reader, because the site gives both a visual shape and a name for it.

The repository layout reflects that. There is a src directory, an i18n directory, and a scripts directory, with no library entry point, no exports field in package.json, and no published artifact described anywhere in the README. The package name is easings.net, which is a site name, not a module name.

How the Site Is Built: Parcel, Pug, PostCSS and YAML

The build is a static site pipeline. package.json defines three scripts: start runs node ./scripts/start.js, build runs NODE_ENV=production node ./scripts/build.js, and lint runs eslint over src and scripts. Parcel is the bundler, and the devDependency list also includes pug for templates, mustache, js-yaml, posthtml, htmlnano, terser and a set of PostCSS plugins.

The PostCSS configuration is where the styling decisions live. The postcss key in package.json enables postcss-dark-theme-class, postcss-pxtorem with a rootValue of 16 and a propList covering font, font-size, line-height, letter-spacing, margin and padding, plus postcss-flexbugs-fixes, postcss-font-family-system-ui and autoprefixer. The pxtorem setup means values written in the source are converted to rem at build time for that property list, with media queries included. If you edit CSS and see no change in output units, that plugin is why.

Localisation is file-based rather than a service. The README says to copy i18n/en.yml to i18n/CODE.yml using a lowercased RFC 3066 language code, giving fr-ca for Canadian French as the example, then translate all messages. js-yaml is a devDependency, so the YAML is read at build time and the strings are baked into the output. There is no runtime translation layer and no key fallback logic documented in the README.

The browserslist entry is defaults, not ie 11, not ie_mob 11. That is a deliberate floor: the site does not target Internet Explorer, and the autoprefixer step follows that list.

Installing easings.net Locally and Running the Dev Server

The README's Test section is the install guide, and it is three steps. Dependencies are installed with yarn, the development server is started with yarn run start, and the README tells you to open localhost:1234 in the browser. There is no npm install instruction and there is no published package to install.

Install the dependencies as the README states:

yarn install

Start the development server:

yarn run start

That script runs node ./scripts/start.js, which is where the server is configured. The README does not document the port as a configurable option; it states that you open localhost:1234. If the page does not load there, the script in scripts/start.js is the file to read, because the README stops at the URL.

For a production build, package.json defines a separate script that sets NODE_ENV before running the build entry point:

NODE_ENV=production node ./scripts/build.js

Or through the package script, which does the same thing:

yarn run build

The README does not describe where the build output lands or how to deploy it. Given that Parcel, terser and htmlnano are all present, the expectation is a minified static bundle, but the output directory is not named in any file you can trace from the README. Check scripts/build.js before wiring this into a deploy pipeline.

Where easings.net Stops Being the Right Tool

The most common mismatch is treating this as a library. There is no dependency you add to an application to get easing functions. The runtime dependency list in package.json contains exactly one entry, focus-visible, which is a focus-ring polyfill and has nothing to do with easing. Everything else is a devDependency for building the site. If you need easing functions inside a JavaScript or TypeScript bundle, this repository does not give you that, and the README does not claim it does.

The second limitation is documentation depth. The README covers contributing, translating and testing. It does not document the site's own API surface, the shape of the data that drives the curves, the build output location, or how to add a new easing function. For a project whose value is a reference table, the absence of a documented way to extend that table is a real gap. Adding a curve means reading src and the i18n YAML yourself.

Third, the translation flow is manual and has no validation described. Copying i18n/en.yml to a new code file and translating every message means a missing or renamed key is something you find by building and looking, not something the README says is checked. The lint script targets src and scripts, not i18n, so a malformed YAML file is not caught by yarn run lint as documented.

Finally, this is a site, not a service. There is no API endpoint, no CDN configuration, and no hosted build documented. If you want the curves in a pipeline, you are extracting them from the source or from the published page yourself.

Alternatives and How Their Approach Differs

The honest alternative for most teams is not another cheat sheet but a runtime easing library, and the difference is structural. A library ships functions you import and call, with a version number you pin in package.json and a changelog you follow. easings.net ships a website you read. The two solve adjacent problems: the library answers "give me the ease-out-cubic function," while the cheat sheet answers "which curve should this be in the first place." A team that already has a timing-curve convention does not need the reference; a team that keeps arguing about whether a transition feels too linear does.

The second alternative is the browser's own keyword set. CSS transitions and animations accept named timing functions, and the platform's built-in set covers the common cases without any dependency at all. The trade-off is granularity: named keywords give you a small fixed menu, while a cheat sheet exists precisely because the interesting choices sit between and beyond those names. If your design system has settled on two or three keywords, a reference site adds nothing.

The third alternative is generating curves from a design tool and pasting the cubic-bezier values directly. That keeps the source of truth in the design file and skips the lookup step. It breaks down when different people need to name the same curve consistently across a codebase, which is the problem a shared reference page actually solves. Note that the README does not compare easings.net to any of these; the choice is yours to make from what each approach costs.

Maintenance, Licence and the Cost of Upgrading

The repository is not archived. Its last push was on 2026-04-07. The repository has no published GitHub releases, so there is no version to pin and no changelog to read. Upgrades happen by pulling the default branch, master, and rerunning yarn install.

That last point is the real maintenance cost. The dependency set is pinned with caret ranges in package.json, and it is a 2020-era stack: Parcel 1.x, TypeScript 4.0, ESLint 7, PostCSS 7, autoprefixer 9. A fresh yarn install resolves within those ranges, but a major-version jump in any of them is a migration, not a bump. The lockfile, yarn.lock, is committed, which is what keeps a clone reproducible; if you fork the site, keep it.

The licence is GPL-3.0, per the LICENSE file at the repository root. That is a copyleft licence. For reading the site or running it locally, the practical effect is minimal. If you fork the source and redistribute a modified version of the site, the licence terms apply to what you distribute, and that is a different situation from linking a permissively licensed animation helper into a closed application. This is not legal advice; if you plan to redistribute a modified build, read the LICENSE file and get your own answer.

One more cost worth naming: because there are no releases, there is no signal separating a content update from a build-tooling change. Every pull is the whole diff.

Editorial conclusion

Adopt easings.net as a reference when you need to choose or verify a timing curve, and treat its source as a static site you can self-host rather than a dependency you import. Do not adopt it expecting a runtime animation library, a published npm package with easing exports, or documentation of an API surface; the README documents only yarn install, yarn run start, the localhost:1234 dev server, and the i18n file convention. Before relying on it, verify which easing names the i18n/en.yml keys expose, whether the GPL-3.0 licence is acceptable for the way you plan to redistribute the site, and how you will track upstream changes given that the last push was on 2026-04-07 and there are no releases to pin against.

Frequently asked questions

Official sources

1. ai/easings.net on GitHub
2. Issues
3. License: GPL-3.0
4. Project website
5. README