25 CSS Footer Designs

A sticky footer sits at the bottom of the viewport ONLY when page content is shorter than the viewport height; once content overflows, the footer scrolls with it and appears at the bottom of the document. A fixed footer stays glued to the viewport bottom permanently, overlaying content. Demo 01 (Sticky Footer to Bottom of Page) is the pattern you almost always want — solved cleanly with either display: flex; flex-direction: column; min-height: 100vh on the body/wrapper with flex: 1 on the main content, OR display: grid; grid-template-rows: 1fr auto; min-height: 100vh on the body wrapper. Both approaches are Pure CSS, zero JavaScript, framework-agnostic. Fixed footers (position: fixed; bottom: 0) belong to specific UI patterns — mobile bottom tab bars, cookie consent banners, urgent CTAs — NOT to standard site footers. A fixed site footer fights every modal, overlay, and mobile keyboard the browser puts up; the sticky-to-bottom pattern is what visitors expect.

Two production-ready approaches. Approach 1 (Pure CSS Grid, recommended for 90% of sites): display: grid; grid-template-columns: repeat(auto-fit, minmax(180px, 1fr)); gap: clamp(24px, 3vw, 48px) on the footer's column container. The auto-fit + minmax combo lets columns reflow from 4-across on desktop → 2 on tablet → 1 on mobile without a single media query. Demo 02 (Responsive 4-Column Footer with Category Links) is the canonical implementation. Approach 2 (progressive disclosure — Demo 08, Mobile-First Collapsible Accordion Footer): keep the multi-column layout on desktop but wrap each column heading in a <details><summary> that becomes clickable ONLY under a mobile breakpoint via @media (max-width: 640px) { summary { pointer-events: auto } } — dense footers like Amazon, Airbnb, and Booking.com use this pattern because 6 columns of 8 links each = 48 links crammed above the fold on mobile, which is worse than 6 collapsed drawers. Both approaches ship WCAG-2.2-AA-compliant focus rings on interactive elements.

The five badges that move enterprise procurement decisions are SOC 2 Type II (proves annual audit of security controls — table-stakes for any B2B SaaS selling to enterprises above $1K ACV), GDPR compliance (EU privacy law, required for any customer in the EEA), HIPAA (US healthcare data protection, mandatory if you touch patient records via BAA with covered entities), PCI DSS (payment card data — required if you process card payments direct, not required if you use Stripe/Adyen/Braintree which handle it), and ISO 27001 (international information-security management, required for enterprise deals in EU + APAC). Demo 10 (SaaS SOC 2 / GDPR / HIPAA Compliance Badge Footer) shows the canonical layout: badge row above a divider + policy-link row below (Privacy · Terms · DPA · Cookies · Security · Trust Center). This isn't decoration — it's a real enterprise-procurement signal. Vercel, Linear, Notion, Stripe, and Slack all ship this exact block. For fintech add PCI DSS + SOC 1 Type II; for healthcare add HIPAA + HITRUST CSF; for government add FedRAMP. Every badge should link to the actual audit report or attestation — a bare logo with no click-through reads as decoration and gets called out by procurement teams.

Payment method icons and security badges are the #1 conversion signal on e-commerce footers — but the wrong approach kills Core Web Vitals. Demo 05 (E-Commerce Footer with Payment Icons & Security Badges) uses the correct pattern: inline SVGs directly in the HTML for the 6-10 payment methods you actually accept (Visa · Mastercard · Amex · Discover · Apple Pay · Google Pay · PayPal · Shop Pay · Klarna · Afterpay). Inline SVGs cost zero HTTP requests, render before First Paint, scale crisply at any resolution, and can be recolored via currentColor or fill: var(--brand). Avoid the classic 2010s pattern of loading a payment-icons sprite PNG (extra HTTP request, blurry on retina) or fetching from a CDN (third-party request, blocks LCP). For SSL / security badges: link out to the actual certificate authority's badge page if you must show them, but the trust signal from a McAfee SECURE seal is genuinely lower today than five years ago — clean site design + real testimonials + real return policy language outperforms trust seals in every 2024-2026 conversion study. Instead of legacy seals, prioritize a real return policy link, a real customer service phone/email, and Trustpilot / Google Reviews integration.

Demo 08 (Mobile-First Collapsible Accordion Footer) is the reference. The rule: activate the accordion behavior ONLY below a viewport threshold where the collapsed state actually improves UX. That threshold is typically 640px (mobile) — above it, keep all columns open because the reader can scan a 4-column grid faster than they can tap-open drawers. The semantic recipe: wrap each column in <details> with the column heading in <summary>, then use @media (min-width: 641px) { .footer details { pointer-events: none } .footer details[open] summary::after, .footer summary::after { display: none } .footer details > :not(summary) { display: block !important; height: auto !important; overflow: visible !important; } } to force-open the details on desktop while suppressing the disclosure caret. Under 641px, native <details> gives you keyboard-accessible expand/collapse for free — Space/Enter opens, Escape closes (browser-native), screen readers announce the disclosure state. Zero JavaScript needed. The pattern Amazon, Airbnb, Booking.com, Wayfair, and Shopify all use because it survives graceful degradation and works with keyboard-only users on the first tab.

The HTML + CSS ports unchanged — every .ft-NN selector, every keyframe, every custom property is framework-agnostic. What changes is where you put the markup. React: extract the footer markup into src/components/Footer.jsx and import from your root layout / page template. Next.js App Router: app/(marketing)/layout.tsx imports and renders <Footer />. Vue 3: single-file component <template><footer class="ft-01">...</footer></template>. Svelte / SvelteKit: src/routes/+layout.svelte renders <Footer />. Astro: src/components/Footer.astro imported by src/layouts/BaseLayout.astro. For any interactive footer (Demo 06 dark-mode toggle, Demo 08 mobile accordion, Demo 13 newsletter signup, Demo 20 contact form, Demo 22 FAQ accordion, Demo 24 language switcher, Demo 25 wave animation), strip the IIFE wrapper from the demo's JS and call the init function from your framework's mount hook (useEffect in React, onMounted in Vue, onMount in Svelte). Next.js App Router requires 'use client' at the top of components that use browser APIs like localStorage or window listeners. Tailwind CSS: the pattern is mechanical translation of each .ft-NN class to utility classes, plus custom-property tokens registered in your @theme block. For fastest ports, wrap the whole footer in a scoped class and paste the demo CSS as-is inside a @layer components block.

Yes — every footer meets WCAG 2.2 AA compliance out of the box. Semantic structure: the outermost element is always <footer>, which is a landmark role screen readers announce as "content info". Navigation regions inside the footer use <nav aria-label="Footer navigation"> so a screen reader user hearing multiple nav landmarks can distinguish them. Icon-only social links carry aria-label="Follow us on Twitter" (never bare icons). Form inputs in newsletter captures pair every <input> with a real <label> — either visible or visually hidden via clip-path: inset(50%) when the visual design demands a placeholder-only field. All interactive elements show a visible :focus-visible ring at 2px minimum thickness and 3:1 contrast against the surrounding background per WCAG 2.4.13 (Focus Appearance, Level AA, added Oct 2023). Hit targets meet the WCAG 2.5.5 44×44 CSS pixel minimum. Every animation (wave motion, gradient drift, hover effects) is wrapped in @media (prefers-reduced-motion: reduce) { animation: none } so the ~15% of adults with vestibular disorders + the ~35% who self-report motion sensitivity don't get nauseated by the footer. Contrast ratios on link text meet the WCAG 1.4.3 4.5:1 minimum in both light and dark themes. Language switchers (Demo 24) correctly update the <html lang="..."> attribute via JS so screen readers pronounce the right language.