fullPage.js: full screen snap scrolling for onepage sites, and the licence that decides whether you can use it

The problem fullPage.js solves, and the licence that decides if you can use it

A normal web page scrolls continuously. A full screen onepage site does not: each section occupies the viewport, and a wheel gesture, swipe or arrow key moves exactly one section. Building that by hand means intercepting wheel and touch events, locking scroll during animation, keeping the URL hash in sync, handling resize, and doing the same again on the horizontal axis for slides inside a section. fullPage.js packages that behaviour behind a small set of options, methods and callbacks, and it adds touch support for phones, tablets and touch screen computers.

The audience is narrow and specific. It fits marketing landing pages, product launches, portfolios and event sites where the narrative is a sequence of screens. It does not fit anything where the reader controls their own pace through long text.

The licence is the first thing to settle, not the last. The package.json declares GPL-3.0. The README splits it in two: if you are creating an open source application under a licence compatible with the GNU GPL v3, you may use fullPage under GPLv3. For non open sourced sites, themes, projects and applications, the Commercial license is described as the appropriate one, keeping your source proprietary. The README also states that you have to provide a prominent notice that fullPage.js is in use, and that the credit comments in the JavaScript and CSS files should be kept intact, even after combination or minification. That last clause is the one teams miss: a build step that strips banner comments from fullpage.min.js and fullpage.min.css puts you outside the stated terms.

How the section and slide model actually works

The structure is two nested levels. Vertical sections are the top level; horizontal slides live inside a section. The README describes the library as creating fullscreen scrolling websites and adding landscape sliders inside the sections, which is exactly this nesting: you scroll down through the page, and within one section you can move sideways.

fullPage.js adds state classes to the DOM as you move, and the README documents a section on those classes. That is the hook most integrations use: instead of polling for position, you style or trigger off the class the library puts on the active element. Callbacks and methods exist alongside, and the repository ships a types/index.d.ts, so TypeScript consumers get the option and callback names from the package rather than from guesswork.

Two options change the mechanics rather than the look. Lazy loading is documented as its own topic, which matters because a full screen site is usually image heavy and a section that is off screen should not be fetching its background yet. The other is css3. With the default CSS3 transform path the library handles movement itself; the README says that when you use css3:false you can optionally add vendors/easings.min.js if you want easing effects other than the built in easeInOutCubic. So the JS animation path has exactly one easing unless you add that file, and that is a real constraint, not a footnote.

There is also a lite build. The package.json defines a limited script that runs rollup.limited.config.js and gulp css-lite, so a reduced distribution exists in the repo's build tooling. The README does not spell out which options the lite build drops, so check the generated output before committing to it.

Install and first page: from npm install to a working two section site

The README offers bower and npm, and both commands are given verbatim. npm is the one most projects will use.

// With bower
bower install fullpage.js

// With npm
npm install fullpage.js

After that, the README's including files example expects the stylesheet, an optional easings script, and the library script. The package ships dist/fullpage.css and dist/fullpage.js (with minified variants), so those are the paths to reference when you copy from node_modules or from a CDN.

<link rel="stylesheet" type="text/css" href="fullpage.css" />

<!-- This following line is optional. Only necessary if you use the option css3:false and you want to use other easing effects rather than "easeInOutCubic". -->
<script src="vendors/easings.min.js"></script>

<script type="text/javascript" src="fullpage.js"></script>

The README states the required markup is the wrapper element with the id fullpage, and each screen is a section element inside it, initialised with new fullpage('#fullpage', options). The global exposed by the library is namespace fullpage_api, per package.json, and the README's methods section is where you look for calls such as moving programmatically. If you use a bundler, the README points to a wiki page on module loaders rather than documenting it inline, which is a gap worth knowing about before you start.

Rather than assemble this blind, the repository carries a large examples/ directory. Files such as examples/active-slide.html, examples/continuous-horizontal.html, examples/fading-effect.html, examples/fixed-headers.html and examples/background-video.html can be opened directly in a browser. That is the fastest way to see which option produces which behaviour, and the README also links a Codepen demo.

Where fullPage.js is the wrong tool

The strongest argument against it is scroll hijacking. When the library owns the wheel event, the reader loses the ability to skim. On a page with eight sections of dense copy, that is hostile. On a page with eight hero images, it is the point.

Accessibility and deep linking need attention. Section state lives in classes the library adds, and the README documents creating links to sections or slides, so hash based navigation is supported. What the README does not document is how a screen reader or a keyboard-only user experiences the snap behaviour, and it does not describe a reduced motion path. If your project has a hard accessibility requirement, treat this as unverified rather than solved.

Browser support is another boundary. The README says fullPage.js is fully functional on all modern browsers and with IE 11, and that if you need to support IE older than 11 you should consider fullPage.js v3, pointing at the 3.1.2 tree. IE 11 itself is a legacy target in 2026, and the library still carries it. That cuts both ways: it is a compatibility guarantee, and it is weight in the bundle.

Finally, the extensions. The README has a section on using extensions and links a separate extensions page, and package.json lists dist/fullpage.extensions.min.js in the published files alongside the plain build. That means some capabilities are not in the base file. If a feature you need turns out to be an extension, your build and your licence conversation both change.

Alternatives, and how they differ in approach

The most direct alternative is the browser itself. CSS scroll snap lets a container declare snap points and the engine handles the gesture, with no wheel interception, no library, and no licence. The difference in approach is ownership: scroll snap keeps native scrolling and tells the browser where to stop, while fullPage.js takes the scroll event and drives the transition. Native snap degrades more gracefully when a section is taller than the viewport, and it does not give you the slide-inside-section model or the callbacks. If your page is a vertical sequence of full height panels and nothing more, scroll snap covers it.

On the framework side, the same author maintains vue-fullpage.js, react-fullpage and angular-fullpage, which the README links. These are wrappers around the same core rather than different engines, so they change how you declare options and lifecycle, not what the library does. Choosing one does not avoid the licence question.

For teams that want a component library rather than a scroll engine, a general purpose UI framework with a carousel or stepper component is the other route. You give up the full screen snap model and gain components you already maintain. That is a fair trade when full screen sections are one page of a larger site rather than the site itself.

Maintenance, upgrade cost and licence implications

The repository is not archived, and the last push was on 2026-03-04, which is the same date as release 4.0.41. Releases 4.0.40 and 4.0.39 landed in December 2025, so the pattern over that window is a small number of patch releases rather than a steady stream. That is normal for a library whose surface is stable, but it means you should not expect new options to arrive quickly.

Upgrade cost is concentrated in major versions. The README links a dedicated migration guide for fullPage v3 to v4, which tells you the v4 line changed enough to require one. Within the 4.0.x series the version numbers are patches. The build here is rollup plus gulp, with jest for tests and a dev watch task, so if you vendor the source rather than the dist files you inherit that toolchain.

On licensing, three things are stated in the README and worth repeating because they are the ones that create work. Non open sourced use is directed to the Commercial license, with source kept proprietary. Open source use is permitted under GPLv3 when your application's licence is compatible. And the credit comments in the JavaScript and CSS files should be kept intact even after combination or minification. That last requirement is a build configuration decision: check whether your minifier is configured to preserve comments in fullpage.min.js and fullpage.min.css. This is a summary of what the README says, not legal advice; if the answer decides your product, ask someone qualified.

Editorial conclusion

Adopt fullPage.js when you are building a marketing, portfolio or product page that is genuinely section-per-screen and you can live with GPL-3.0 or buy the commercial licence. Skip it for content-heavy documentation, long-form articles or dashboards, where forced snapping fights the reader. Before writing markup, confirm two things: whether your project can ship under GPL-3.0 with the credit comments in fullpage.js and fullpage.css kept intact, and whether the option you need sits in the free build or in an extension, since the extensions are bundled separately as dist/fullpage.extensions.min.js.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes