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=1tells 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.
Recommended file structure
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.