What Is a UI Bug or Glitch? Meaning, Examples, and Fixes

Last updated: November 6, 2026

A UI bug, also called a UI glitch or UI issue, is a visible defect in an interface: the feature may work, but it looks or behaves differently from the design. The six most common types are typography errors, spacing misalignment, color inconsistencies, interactive state failures, responsive breakages, and component implementation gaps.

Visual bugs are everywhere. The majority of shipped features contain at least one visual discrepancy from the approved design. Not functionality issues, visual ones. Wrong font weight, incorrect padding, missing hover state. According to the National Institute of Standards and Technology (NIST), the longer a defect goes undetected, the more it costs to fix: in its 2002 study of the financial-services sector, a requirements error found only after release cost about 15 times as much to fix as one caught during requirements. Visual bugs that slip past design review compound that cost across every subsequent sprint.

Users notice. Stanford's Web Credibility Project found that visual design is what people comment on most when judging whether a website is credible (46.1% of their comments). First impressions form in 50 milliseconds. A button with wrong padding or a heading in the wrong weight signals carelessness, even if the feature works perfectly. A figure widely attributed to Forrester Research (a paywalled 2016 report) puts the return on UX investment at up to $100 for every dollar spent. Visual bugs erode that return by degrading the experience users actually see.

The problem is not that designers spec poorly or that developers ignore specs. The problem is that the design-to-code pipeline has dozens of points where visual fidelity can break down, and most teams have no systematic process for catching these failures.

This guide covers the six most common categories of UI bugs, with real examples and practical prevention strategies for each. A structured design QA process catches the majority of these before they reach production.

UI Bug Category	Example	Prevention
Typography errors	Font renders at weight 400 instead of 600	Typography tokens mapped to CSS custom properties
Spacing misalignment	Card uses 20px padding instead of specified 24px	8pt grid system with named spacing tokens
Color inconsistencies	Gray renders as #666 instead of design spec #6B7280	Semantic color tokens with automated contrast checks
Interactive state failures	Button has no focus indicator for keyboard users	Component state matrix for all interaction states
Responsive breakages	Three-column grid overlaps at tablet widths	Multi-device QA at 375px, 768px, and 1440px
Component drift	Same button is 40px in header but 36px in modal	Shared component library as single source of truth

All six categories can be detected without a human reading the page. Automated design review runs 34 deterministic checks that map onto this table: typography, spacing, color and component drift are caught as design inconsistencies, interactive state failures as missing hover, focus, active, disabled and error styles, and responsive breakages as fixed widths, unbounded images and clipped text. Knowing the categories is what makes the findings readable.

Typography and Text Rendering Issues

Typography bugs are the most frequent UI defect category. Wrong font-weight, mismatched line-height, letter-spacing drift: these discrepancies arise because Figma, Sketch, and Adobe XD each render text through their own engine, while browsers rely on platform-level rasterizers (Blink in Chrome, WebKit in Safari, Gecko in Firefox) that produce subtly different results. A heading renders at font-weight 400 instead of 600. Body text uses 15px instead of 16px. Line-height is 1.4 instead of 1.5. Each deviation is small. Together, they make a page feel 'off' in a way that's hard to articulate but easy to perceive.

Common typography bugs:

Incorrect font families or weights: The design uses Inter Semi Bold. The implementation loads Inter Regular. This happens when developers reference the font by family name without specifying weight explicitly.
Line-height and letter-spacing discrepancies: Design tools and CSS handle line-height differently. Design tools specify line-height in pixels (e.g., 28px). CSS developers often use unitless ratios (e.g., 1.5). The conversion introduces drift.
Text truncation and overflow: A heading looks perfect with placeholder text. With real content, it wraps to a third line and breaks the layout. Truncation rules were never specified in the design.

Tip: Prevention: Establish typography tokens. Define font-family, font-weight, font-size, line-height, and letter-spacing as named tokens in your design system. Map those tokens directly to CSS custom properties. When the token says "heading-lg," both the design tool and code should resolve to the exact same values. Test with realistic content, not "Lorem ipsum" but actual product copy at its longest expected length.

Spacing and Alignment Problems

Spacing and alignment bugs are the second most common design QA finding, caused by inconsistent padding, margin, and gap values between the Figma spec and CSS implementation. Prevention requires an 8pt grid system with named design tokens (space-sm, space-md, space-lg) enforced through CSS custom properties and linting rules in tools like Stylelint. These bugs are the most tedious to fix manually because they require measuring pixel values between elements, often across nested containers where padding compounds.

Common spacing bugs:

Padding and margin inconsistencies: A card uses 24px padding in the design but 20px in implementation. Or worse, one card in a grid uses 24px while its sibling uses 16px because two developers implemented them independently.
Misaligned elements and broken grid systems: A form label sits 2px higher than its input. A navigation item breaks out of the baseline grid. These misalignments are invisible in isolation but create visual noise when the full page renders.
Insufficient whitespace: Sections feel cramped because margins between them are smaller than specified. Developers often reduce whitespace to "fit more above the fold," not realizing they are overriding deliberate design decisions about visual breathing room.

Tip: Prevention: Use design tokens and an 8pt grid system. When every spacing value is a multiple of 8 (8, 16, 24, 32, 40), developers have fewer choices to make and fewer ways to go wrong. Define spacing tokens (space-sm: 8px, space-md: 16px, space-lg: 24px) and enforce them in code. Use CSS gap properties instead of individual margins where possible: gap is harder to apply inconsistently.

Color and Visual Hierarchy Mistakes

Color inconsistencies between design specs and live code erode brand consistency faster than any other UI bug category, and they create WCAG 2.2 accessibility violations when contrast ratios fall below the 4.5:1 AA threshold. The WebAIM Million 2025 report found that 95.9% of the top one million homepages had detectable WCAG failures, with low contrast text as the single most common error. A shade of gray that's #6B7280 in the Figma spec renders as #666666 in code. Multiply that drift across 40 components and your product's palette becomes a smudge of almost-right values that tools like axe-core and Lighthouse flag as violations.

Common color bugs:

Off-brand grays and incorrect color values: Most products use 4-6 gray shades. Developers who eyeball these values instead of referencing tokens introduce subtle palette drift that compounds across the product.
Insufficient color contrast for accessibility: A gray text on a light background looks fine on a high-end monitor. On a standard laptop screen, it fails WCAG AA contrast requirements and becomes unreadable for users with low vision. The WebAIM Million 2025 report found that 95.9% of the top one million homepages had detectable WCAG failures, with low contrast text as the most common error category.
Inconsistent use of color across components: Primary blue is used for links in the sidebar but for backgrounds in the header. Active states use green in one view and blue in another. Without explicit rules, color meaning becomes ambiguous.

Tip: Prevention: Implement color tokens with semantic naming (color-text-primary, color-bg-surface, color-border-default) and run automated contrast checking in CI. Tools like axe-core flag WCAG AA violations before code reaches staging. Semantic naming prevents developers from reaching for raw hex values.

Interactive State Failures

Interactive state failures happen when a product ships with missing or inconsistent hover, focus, active, disabled, loading, or error states. Focus indicators carry particular weight: WCAG 2.2 Success Criterion 2.4.7 requires visible focus for keyboard navigation, so a missing focus ring is both a visual bug and an accessibility violation that axe-core and Lighthouse will flag. Designers typically spec the default state, sometimes hover. They rarely document the remaining states. Developers implement what they receive and leave the rest to browser defaults.

Common interactive state bugs:

Missing hover and focus states: A button has no hover effect, making it feel unresponsive. Or worse, it has a hover state but no focus state, making it inaccessible to keyboard users.
Incorrect disabled state styling: Disabled buttons use full opacity with a "not-allowed" cursor. Users still expect them to be clickable because they look enabled. Proper disabled styling uses reduced opacity and removes interactive affordances.
Loading state implementation gaps: A form submits but shows no loading indicator. Users click again. The form submits twice. Loading states are not cosmetic: they prevent duplicate actions.

Tip: Prevention: Create a state matrix for every component: default, hover, focus, active, disabled, loading, error, empty, and skeleton. Not every component needs every state, but every component needs an explicit decision about which states it supports and how they look. Include state documentation in your design handoff as a required deliverable, not an afterthought.

Responsive Design Breakages

Responsive design breakages are the most expensive UI bug category to fix late because they require structural changes to CSS Grid, Flexbox, or container query logic rather than simple value tweaks. Testing must cover at least three breakpoints: mobile (375px), tablet (768px), and desktop (1440px) on actual devices, not just browser simulation. A card grid that works perfectly at 1440px collapses into overlapping elements at 768px. The stakes are tangible: Google and Deloitte (2020) found that a 0.1-second improvement in mobile site speed increased retail conversion rates by 8.4%. Layout breakages that cause reflows and content shifts directly hurt that performance.

Common responsive bugs:

Mobile layout inconsistencies: A three-column layout doesn't stack to a single column on mobile. A hero section that looks balanced on desktop becomes text-heavy with a tiny image on phones.
Broken text alignment on different screen sizes: Centered text at desktop widths creates awkward short lines at narrow widths. A paragraph that reads comfortably at 600px wide becomes a single-word-per-line column at 320px.
Image scaling and overflow issues: Images overflow their container at narrow widths. SVG icons scale disproportionately. Background images lose their focal point when cropped by different aspect ratios.

Tip: Prevention: Build a multi-device design QA process. Test at a minimum three breakpoints: mobile (375px), tablet (768px), and desktop (1440px). Don't just resize your browser. Test on actual devices where touch targets, text rendering, and viewport behavior differ from desktop simulation. Include responsive checks in your design QA checklist as a required step before marking any ticket as "done."

Component Implementation Discrepancies

Component implementation discrepancies occur when the same UI element, such as a button, card, or input field, is implemented with different dimensions, padding, or styling across different pages or contexts. This is the core design system problem that atomic design methodology and shared component libraries in React, Vue, or Angular are designed to solve. Without a single source of truth maintained in tools like Storybook or Figma's component library, variations multiply across the codebase. Tools like BugHerd, Marker.io, and OverlayQA help teams capture these inconsistencies with enough context for developers to fix them.

Common component bugs:

Button sizing and styling variations: The primary button in the header is 40px tall. The primary button in the modal is 36px. The primary button in the form is 44px. Same design system token, three implementations.
Form field inconsistencies: Input fields use different border radius, padding, and placeholder styles across different forms. Date pickers and select dropdowns don't match the design system's input pattern.
Icon misalignments and sizing issues: Icons are vertically misaligned with adjacent text. Different icon sets use different optical sizes, so a 16px icon from one set looks smaller than a 16px icon from another.

Tip: Prevention: Build and maintain a component library. Define each component once, with all its variants and states, in both the design tool and the codebase. When a developer needs a button, they import the button component; they don't create a new element with custom styles. Audit your codebase quarterly for components that have drifted from the design system specification.

Frequently Asked Questions

What is a UI glitch?

Usually the same thing as a UI bug: something on screen looks or behaves wrong, even if the feature underneath still works, such as overlapping text, a flicker, or a button with no hover state. A UI issue means the same. The fix starts the same way: find the element, compare it with the design, and check it at each breakpoint.

What are the most common UI bugs in web applications?

Six categories account for most visual bugs: typography drift (wrong font size, weight, or line-height), spacing errors (incorrect padding or margin), color mismatches (hex values that are close but not identical to the spec), component state issues (missing hover, focus, or disabled styles), responsive breakpoint bugs (layout breaks between defined breakpoints), and border radius inconsistencies.

How do you prevent UI bugs before they ship?

Design QA at the staging level: comparing the live implementation against the design spec before merge. Teams that run a visual comparison pass on every PR catch 90% of UI bugs before they reach production. The key is making comparison fast enough to fit into the sprint cycle, not a post-launch audit. File visual issues in Jira or Linear with CSS values and screenshots so they get prioritized alongside functional bugs.

What is the difference between a UI bug and a design debt issue?

A UI bug is a specific, fixable discrepancy: the padding is 12px when the spec says 20px. Design debt is accumulated drift across many small discrepancies that were never caught or prioritized. Individual UI bugs become design debt when they are ignored. A design QA process prevents both by catching discrepancies at the PR level.

What causes UI bugs in frontend development?

UI bugs originate from four main sources: translation loss during design-to-code handoff (developers interpret specs differently than intended), missing design specifications (interactive states, edge cases, and responsive behavior left unspecified), design token drift (hardcoded values replacing shared tokens over time), and cross-browser rendering differences (browsers handle fonts, sub-pixel rounding, and CSS properties inconsistently).

How much do UI bugs cost to fix in production?

According to the National Institute of Standards and Technology (NIST), the longer a defect goes undetected, the more it costs to fix: in its 2002 study of the financial-services sector, a requirements error found only after release cost about 15 times as much to fix as one caught during requirements. A font-weight discrepancy takes seconds to fix during a structured design QA review but hours when reported via a customer screenshot that requires reproduction, triage, assignment, and context rebuilding.

Building a Preventative UI Bug Strategy

Every UI bug category covered above has a known prevention strategy. Design tokens eliminate wrong-value bugs. Axe-core and Lighthouse catch WCAG 2.2 contrast violations in CI. Storybook component libraries prevent implementation drift. Multi-device testing at 375px, 768px, and 1440px catches responsive breakages before users do. The pattern is consistent: systematic tooling beats manual vigilance.

The common thread is systematic prevention over reactive debugging. Catching a font-weight discrepancy takes seconds during a structured design QA review. Catching it from a customer screenshot takes hours.

Three practical steps to start:

Build a website QA checklist that covers each category listed in this guide
Run design QA mid-sprint: after code-complete, before sprint review
Use design tokens to eliminate the entire class of "wrong value" bugs

Visual consistency is not polish. It is product quality. Teams that invest in preventing UI bugs spend less time fixing them and ship products that earn user trust from the first interaction.

For a deeper dive into setting up a design QA process, explore the complete guide to design QA, compare design QA tools across the four workflow stages, or see how visual comparison tools automate the detection of many of these bug categories. The hidden cost of manual bug reporting explains why catching these issues early saves significantly more than just developer time.

OverlayQA catches the most common UI bugs before they ship. Detect spacing, typography, and color issues automatically with AI analysis, CSS extraction, and accessibility auditing. Export structured tickets to Jira, Linear, Asana, or Trello.