Getting Started

This section documents Bootstrap 5.x as implemented by the official Bootstrap project. No specific patch version is pinned. Unlike the other reference sections on this site, no single reference book underpins it: the content was generated with the assistance of AI from general knowledge of Bootstrap, and should be verified against the current official documentation at getbootstrap.com/docs before relying on it in production.

This section’s bibliography lists the reference material consulted while preparing these pages.

Bootstrap is a CSS framework — a stylesheet plus a small set of JavaScript components — that ships a consistent, responsive set of building blocks so a project does not have to invent its own grid, typography scale, and form controls from scratch. Every other page in this section assumes one of the installation methods below is already wired into the page or the build.

Installation methods

There are three ways to bring Bootstrap into a project, and the right one depends on how the rest of the project is built.

CDN

The fastest way to get started — no build step, no local files, nothing to install. Add a <link> for the compiled CSS in the <head> and a <script> for the bundled JavaScript (which includes Popper.js for positioning dropdowns, tooltips, and popovers) just before the closing </body>:

<!-- CSS, in <head> -->
<link
  href="https://cdn.jsdelivr.net/npm/bootstrap@5.3.3/dist/css/bootstrap.min.css"
  rel="stylesheet"
  integrity="sha384-QWTKZyjpPEjISv5WaRU9OFeRpok6YctnYmDr5pNlyT2bRjXh0JMhjY6hW+ALEwIH"
  crossorigin="anonymous">

<!-- JS bundle (Bootstrap + Popper), just before </body> -->
<script
  src="https://cdn.jsdelivr.net/npm/bootstrap@5.3.3/dist/js/bootstrap.bundle.min.js"
  integrity="sha384-YvpcrYf0tY3lHB60NNkmXc5s9fDVZLESaAA55NDzOxhy9GkcIdslK1eN7N6jIeHz"
  crossorigin="anonymous"></script>

The integrity and crossorigin attributes enable Subresource Integrity checking, so the browser refuses to execute the file if the CDN ever serves something other than the expected bytes. Always copy the current hashes from the official site rather than reusing an old pair against a different version — they are version-specific.

The CDN link ships compiled CSS: the Sass source is not available this way, so no variable can be customized. Use it for prototypes, demos, or any project that has no build pipeline. For anything requiring Sass customization, use the package manager route instead.

Package manager (npm / yarn)

For a project that already has a Node-based build (Vite, Webpack, or similar), install Bootstrap as a dependency:

npm install bootstrap@5.3.3
# or
yarn add bootstrap@5.3.3

This pulls in both the precompiled dist/css/dist/js files and the Sass source under scss/, which is what makes customization possible — import scss/bootstrap (or a subset of its partials) into your own stylesheet and override its !default variables before that import, exactly as described in Variables. Popper.js is pulled in automatically as a dependency of bootstrap.bundle.js; installing it separately is only needed if importing Bootstrap’s individual JS modules rather than the bundle.

// main.scss
$primary: #6f42c1;                 // override before the import
@import "bootstrap/scss/bootstrap";

Downloading the compiled source

For a project with no package manager and no build tool at all, the official site offers a ZIP of the precompiled CSS/JS files (and, separately, the raw Sass/JS source). Unzip it, copy dist/css and dist/js into the project, and reference them with local <link>/<script> tags instead of the CDN URLs. This trades the CDN’s shared-cache benefit for full control over hosting — useful for offline environments or strict content-security-policy setups that disallow third-party script origins.

See the official Download page for the current ZIP links, and the Introduction page for a fuller walkthrough of all three methods.

The minimal starter template

Bootstrap’s CSS assumes a specific <head> baseline. Skipping any of these three pieces produces subtly broken rendering — most commonly, an unstyled or badly-scaled mobile layout:

<!doctype html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>Starter template</title>

    <link
      href="https://cdn.jsdelivr.net/npm/bootstrap@5.3.3/dist/css/bootstrap.min.css"
      rel="stylesheet">
  </head>
  <body>
    <h1>Hello, world!</h1>

    <script
      src="https://cdn.jsdelivr.net/npm/bootstrap@5.3.3/dist/js/bootstrap.bundle.min.js"></script>
  </body>
</html>

Three requirements in that template are not optional:

  • <meta charset="utf-8"> — must be the very first child of <head> so the browser never has to re-parse the document under a different encoding guess.

  • The viewport <meta> tag — width=device-width, initial-scale=1 tells mobile browsers to render at the device’s actual CSS-pixel width instead of a desktop-sized virtual viewport zoomed out to fit. Without it, Bootstrap’s responsive breakpoints (see The Grid System) never trigger correctly on a phone — the page always measures as a wide desktop viewport.

  • <!doctype html> — Bootstrap relies on standards-mode box-sizing and rendering rules; omitting the doctype drops the page into quirks mode, which changes box-model and layout behavior unpredictably (see The Box Model).

The JavaScript bundle is only needed for pages using an interactive component (dropdowns, modals, tooltips, carousels, offcanvas, etc.). A purely static page that only uses layout and typography utilities can omit the <script> tag entirely and ship a bit less JavaScript to the client.

For a project without a bundler, a conventional flat layout keeps vendor files separate from project files:

project/
├── index.html
├── css/
│   └── styles.css        # project-specific overrides, loaded after Bootstrap's CSS
├── js/
│   └── main.js            # project-specific scripts, loaded after the Bootstrap bundle
└── vendor/
    └── bootstrap/
        ├── css/
        │   └── bootstrap.min.css
        └── js/
            └── bootstrap.bundle.min.js

The ordering matters in both the CSS and the JS: Bootstrap’s stylesheet must load before any project stylesheet that overrides it (later rules of equal specificity win), and the Bootstrap JS bundle must load before any project script that calls into its component APIs (bootstrap.Modal, bootstrap.Tooltip, and so on are only defined once the bundle has executed).

Browser and OS support

Bootstrap 5 targets the current stable and previous major releases of the popular evergreen browsers — Chrome, Firefox, Safari, and Edge — on both desktop and mobile, plus recent iOS and Android versions for mobile Safari/Chrome. Internet Explorer is not supported as of Bootstrap 5 (support was dropped along with the IE-specific polyfills and CSS carried by Bootstrap 4); a project that still needs IE 11 must stay on Bootstrap 4 or ship its own fallback styling.

Because Bootstrap 5 also dropped the jQuery dependency present in Bootstrap 4 and earlier, its JavaScript components are plain ES modules running against the browser’s native DOM APIs — there is no jQuery version compatibility matrix to track anymore.

Accessibility basics

Bootstrap’s own components ship with reasonable ARIA defaults (for example, the modal and dropdown JavaScript manage aria-expanded, aria-hidden, and focus trapping automatically), but the framework cannot guarantee an accessible page on its own — that still depends on how it is used:

  • Use real semantic HTML elements (<nav>, <button>, <header>) rather than styling a <div> to look like one; Bootstrap’s classes are visual, not semantic.

  • Keep a single visible focus order that matches the visual reading order — utilities that reorder columns visually (see The Grid System) do not reorder the underlying DOM, so keyboard/screen-reader navigation follows the source order regardless of how it looks.

  • Do not rely on color alone to convey meaning — the color utility classes should be paired with text or an icon for anything meaningful (an error state, a required field).

  • Verify contrast: Bootstrap’s default theme colors are chosen to meet WCAG AA against their typical background, but a customized or overridden palette (see Customization) is not automatically re-checked — that verification is the integrator’s responsibility.

The official site publishes a dedicated Accessibility page covering these points, plus component-specific notes, in more depth.