Understanding CSS Padding vs. Margins

Most web development professionals are familiar with the terms CSS padding and margins — but do you know the margin vs padding difference?

Padding and margins allow you to style your site’s elements in a way that allows your gorgeous design to shine through and produce a solid, successful customer conversion experience for your web design clients.

In Duda, which was created to make website building more efficient for web pros, you can control CSS margins and padding easily without diving into the code. But whether you use Duda to build sites or not, you’ll want to understand the finer points of CSS padding vs. margins to become a true command-line pro.

A Brief Overview of CSS

Before we dive in, let’s look at how CSS works at its core. All CSS uses the CSS box model for design, which essentially puts a box — transparent or otherwise — around every HTML element.

You add your content with text and images, you add a padding value to provide a clean transparent area around the content, you often include a border around the padding and content, and then the margin value adds a transparent area outside of the border. Margins determine the amount of space between adjacent elements, or whitespace.

CSS Padding vs. Margins

In CSS, the margin is the space around an element, while padding is the space between an element and the content inside of it.

Margin is outer space of an element, while padding is inner space of an element. If you add padding to an inline element, the changes will only occur on the sides of an element (right and left), not on its top and bottom.

Below, we’ll see when and how to apply them. But first, we need to review a couple other basics.

Two important things to know

The default value of both padding and margin properties is 0, meaning that any elements that can be changed with CSS by default have no extra spacing.
You can change the type of box used. Browsers default to the W3C box model, which computes the width of the element to be equal to the content of the box excluding its padding and border, explains Sitepoint. But you can specify the traditional box model, which considers the width of the element to be equal to the sum of the content, padding and the border. Here’s how SitePoint illustrates the differences:

Use the following code to set up a traditional box model:

When to use padding

Understanding how to use padding is essential when making adjustments to most design elements in most platforms.

Padding is to be used when:

You don’t want your content to touch the edges of the container. An example is when you have paragraph elements inside a div and you don’t want the text inside the <p> elements to touch the div’s border.
You want the background of the element to be displayed in the produced gap. For instance, padding adjustments are needed if you’re building two divs side-by-side and you want both divs to touch each other, but don’t want their texts to touch. Add the padding to put space between the element and the content inside it.
You want to increase the size of the element. For example, you would use padding if you want to increase the size of a button.

Here is a code example of how to set padding:

If you don’t have to set all four of these individually, the padding property allows you to set them all in one declaration, which goes clockwise around the element, like this:

Instead of specifying the length using pixels, you can also use pt, cm and other measurements. Another way to set padding is to use the percentage command. When using percentages, the percentage is set relative to the width of the containing element. Here’s an example of code:

When you’re changing a button size with padding, you can use code like this:

 .button {
  background-color: #4CAF50; /* Green */
  border: none;
  color: white;
  padding: 15px 32px;
  text-align: center;
  text-decoration: none;
  display: inline-block;
  font-size: 16px;
}

This can be increased or decreased to change the size, as illustrated by W3Schools.

.button1 {padding: 10px 24px;}
.button2 {padding: 12px 28px;}
.button3 {padding: 14px 40px;}
.button4 {padding: 32px 16px;}

When to use margins

Margins are another way to take control of design elements. Here are a few reasons you may want to adjust margins:

Center an element. If you give “margin: auto” to an element with fixed width, it will center that element horizontally.
Provide space around an element. For instance, when you don’t want the element to touch other elements around it, use margins.

The four margins are the same as you set for padding, but look like this:

Margin-top
Margin-right
Margin-bottom
Margin-left

Like with padding, you can use shortcuts instead of specifying each margin and can do it all in one command (with the order going around the element clockwise):

If you specify one value, that value applies the same margin on all four sides. Use two values and the first margin applies to the top margin and bottom margin and second to the left margin and right margin. If using three values, the first applies to the top, then the second to both right and left, then third to the bottom.

You can also use percentages for margins. Or you can use command “auto” to allow the browser to calculate a margin. You can also use “initial” to set the CSS property to default the margin as the default set elsewhere on the web page when you change another item like color. You can also use the command “inherit” to set the margin to the parent element. To get a more in-depth understanding of these commands, check out this W3Schools resource.

Unlike with padding, you can use negative values in margins. Negative margins will draw the element closer to its neighbors and create overlap elements. However, one of the main problems when you set margins is margin collapsing, and this commonly occurs when smaller margins overlap into larger ones.

How to Apply This in Duda

In Duda’s website builder, it’s simpler to make these adjustments than using CSS or HTML code. You can easily specify the spacing and border of an elements, including padding and margins, by right-clicking the element on any widget, element, column, or row and then clicking Edit Design and the Spacing tab.

You can choose to use Containers and Flexboxes Edit the element’s content area and every part of the design super easily. The main difference between Duda and other website builders is that you don’t need numerous tutorials, or extensive coding experience to build websites, but you still have all the customization you need.

Putting CSS Margins & Padding to Work

Start using the various methods of implementing padding and margins today to see which methods work best depending on your need. In no time at all, you’ll understand the difference between CSS padding and margins and know how to use them appropriately.

Related: How To Create A Fixed Header

Core web vitals: What agencies need to know in 2026

By Shawn Davis • April 1, 2026

Core Web Vitals aren't new, Google introduced them in 2020 and made them a ranking factor in 2021. But the questions keep coming, because the metrics keep changing and the stakes keep rising. Reddit's SEO communities were still debating their impact as recently as January 2026, and for good reason: most agencies still don't have a clear, repeatable way to measure, diagnose, and fix them for clients. This guide cuts through the noise. Here's what Core Web Vitals actually measure, what good scores look like today, and how to improve them—without needing a dedicated performance engineer on every project. What Core Web Vitals measure Google evaluates three user experience signals to determine whether a page feels fast, stable, and responsive: Largest Contentful Paint (LCP) measures how long it takes for the biggest visible element on a page — usually a hero image or headline — to load. Google considers anything under 2.5 seconds good. Above 4 seconds is poor. Interaction to Next Paint (INP) replaced First Input Delay (FID) in March 2024. Where FID measures the delay before a user's first click is registered, INP tracks the full responsiveness of every interaction across the page session. A good INP score is under 200 milliseconds. Cumulative Layout Shift (CLS) measures visual stability — how much page elements unexpectedly move while content loads. A score below 0.1 is good. Higher scores signal that images, ads, or embeds are pushing content around after load, which frustrates users and tanks conversions. These three metrics are a subset of Google's broader Page Experience signals, which also include HTTPS, safe browsing, and mobile usability. Core Web Vitals are the ones you can most directly control and improve. Why your clients' scores may still be poor Core Web Vitals scores vary dramatically by platform, hosting, and how a site was built. Some of the most common culprits agencies encounter: Heavy above-the-fold content . A homepage with an autoplay video, a full-width image slider, and a chat widget loading simultaneously will fail LCP every time. The browser has to resolve all of those resources before it can paint the largest element. Unstable image dimensions . When an image loads without defined width and height attributes, the browser doesn't reserve space for it. It renders the surrounding text, then jumps it down when the image appears. That jump is CLS. Third-party scripts blocking the main thread . Analytics pixels, ad tags, and live chat tools run on the browser's main thread. When they stack up, every click and tap has to wait in line — driving INP scores up. A single slow third-party script can push an otherwise clean site into "needs improvement" territory. Too many web fonts . Each font family and weight is a separate network request. A page loading four font files before rendering any text will fail LCP, especially on mobile connections. Unoptimized images . JPEGs and PNGs served at full resolution, without compression or modern formats like WebP or AVIF, add unnecessary weight to every page load. How to measure them accurately There are two types of Core Web Vitals data you should be looking at for every client: Lab data comes from tools like Google PageSpeed Insights, Lighthouse, and WebPageTest. It simulates page loads in controlled conditions. Lab data is useful for diagnosing specific issues and testing fixes before you deploy them. Field data (also called Real User Monitoring, or RUM) comes from actual users visiting the site. Google collects this through the Chrome User Experience Report (CrUX) and surfaces it in Search Console and PageSpeed Insights. Field data is what Google actually uses as a ranking signal — and it often looks worse than lab data because it reflects real-world device and connection variability. If your client's site has enough traffic, you'll see field data in Search Console under Core Web Vitals. This is your baseline. Lab data helps you understand why the scores are what they are. For clients with low traffic who don't have enough field data to appear in CrUX, you'll be working primarily with lab scores. Set that expectation early so clients understand that improvements may not immediately show up in Search Console. Practical fixes that move the needle Fix LCP: get the hero image loading first The single most effective LCP improvement is adding fetchpriority="high" to the hero image tag. This tells the browser to prioritize that resource over everything else. If you're using a background CSS image for the hero, switch it to anelement — background images aren't discoverable by the browser's preload scanner. Also check whether your hosting serves images through a CDN with caching. Edge delivery dramatically reduces the time-to-first-byte, which feeds directly into LCP. Fix CLS: define dimensions for every media element Every image, video, and ad slot on the page needs explicit width and height attributes in the HTML. If you're using responsive CSS, you can still define the aspect ratio with aspect-ratio in CSS while leaving the actual size fluid. The key is giving the browser enough information to reserve space before the asset loads. Avoid inserting content above existing content after page load. This is common with cookie banners, sticky headers that change height, and dynamically loaded ad units. If you need to show these, anchor them to fixed positions so they don't push content around. Fix INP: reduce what's competing for the main thread Audit third-party scripts and defer or remove anything that isn't essential. Tools like WebPageTest's waterfall view or Chrome DevTools Performance panel show you exactly which scripts are blocking the main thread and for how long. Load chat widgets, analytics, and ad tags asynchronously and after the page's critical path has resolved. For most clients, moving non-essential scripts to load after the DOMContentLoaded event is a meaningful INP improvement with no visible impact on the user experience. For websites with heavy JavaScript — particularly those built on frameworks with large client-side bundles — consider breaking up long tasks into smaller chunks using the browser's Scheduler API or simply splitting components so the main thread isn't locked for more than 50 milliseconds at a stretch. What platforms handle automatically One of the practical advantages of building on a platform optimized for performance is that many of these fixes are applied by default. Duda, for example, automatically serves WebP images, lazy loads below-the-fold content, minifies CSS, and uses efficient cache policies for static assets. As of May 2025, 82% of sites built on Duda pass all three Core Web Vitals metrics — the highest recorded pass rate among major website platforms. That baseline matters when you're managing dozens or hundreds of client sites. It means you're starting each project close to or at a passing score, rather than diagnosing and patching a broken foundation. How much do Core Web Vitals actually affect rankings? Honestly, they're a tiebreaker — not a primary signal. Google has been clear that content quality and relevance still dominate ranking decisions. A well-optimized site with thin, irrelevant content won't outrank a content-rich competitor just because its CLS is 0.05. What Core Web Vitals do affect is the user experience that supports those rankings. Pages with poor LCP scores have measurably higher bounce rates. Sites with high CLS lose users mid-session. Those behavioral signals — time on page, return visits, conversions — are things search engines can observe and incorporate. The practical argument for fixing Core Web Vitals isn't just "because Google said so." It's that faster, more stable pages convert better. Every second of LCP improvement can reduce bounce rates by 15–20% depending on the industry and device mix. For client sites that monetize through leads or eCommerce, that's a revenue argument, not just an SEO argument. A repeatable process for agencies Audit every new site before launch. Run PageSpeed Insights and record LCP, INP, and CLS scores for both mobile and desktop. Flag anything in the "needs improvement" or "poor" range before the client sees the live site. Check Search Console monthly for existing clients. The Core Web Vitals report surfaces issues as they appear in field data. Catching a regression early — before it compounds — is significantly easier than explaining a traffic drop after the fact. Document what you've improved. Clients rarely see Core Web Vitals scores on their own. A monthly one-page performance summary showing before/after scores builds credibility and makes your technical work visible. Prioritize mobile. Google uses mobile-first indexing, and field data shows that mobile CWV scores are almost always worse than desktop. If you only have time to optimize one version, do mobile first. Core Web Vitals aren't a one-time fix. Platforms change, new scripts get added, campaigns bring in new widgets. Build the audit into your workflow and treat it like any other ongoing deliverable, and you'll stay ahead of the issues before they affect your clients' rankings. Duda's platform is built with Core Web Vitals performance in mind. Explore how it handles image optimization, script management, and site speed automatically — so your team spends less time debugging and more time building.

Why systems, not tools, are the future of vertical SaaS

By Ilana Brudo • March 31, 2026

Vertical SaaS must transition from tools to an AI-powered Vertical Operating System (vOS). Learn to leverage context, end tech sprawl, and maximize retention.

Maximizing SaaS growth with an API-driven website builder

By Shawn Davis • March 27, 2026

Automate client management, instant site generation, and data synchronization with an API-driven website builder to create a scalable growth engine for your SaaS platform.