- Published
- Byline
- GoHighLevel Partners Editorial
- Filed under
- GoHighLevel Automation
Width is set in three places that each mean something different, and all three exist separately for every screen size.
Row column width settings: where the space actually goes
Rows and columns are the only structural decision in a page builder that touches every element on the page. Everything else — a button, an image, a form — sits inside a column, and the column’s width decides how much room it gets, when it wraps, and whether the layout survives a narrow screen. Get the widths right and the rest of the page mostly builds itself. Get them wrong and you spend the afternoon nudging padding on individual elements to compensate for a container that was never the right size.
The confusion comes from width being set in three places that each mean something different, and from the same three settings existing separately for each screen size.
Three levels, three different questions
| Level | What it controls | The question it answers |
|---|---|---|
| Section | Whether the background spans the whole viewport | Does the colour or image reach the browser edges? |
| Row | The maximum width the content is allowed to occupy | How wide is the reading column on a large monitor? |
| Column | How the row’s width is divided, plus its own padding | How much of that width does this piece of content get? |
A full-width section containing a constrained row is the normal arrangement: the background reaches the edges, the text stays inside a comfortable measure. The layout that looks broken on a wide monitor is usually a row set to full width as well, so a paragraph runs the entire span of the screen and becomes tiring to read.
Column widths are shares, not sizes
A column’s width is a proportion of the row it sits in, not an absolute measurement. Two columns at fifty per cent each split whatever the row happens to be. Change the row’s maximum width and both columns change with it, which is why adjusting one number at row level often fixes a layout that seemed to need six adjustments at column level.
The shares in a row are expected to total one hundred. Where a builder offers preset splits — halves, thirds, a two-thirds and one-third pairing — those presets exist because they total cleanly. Custom values that do not add up either leave a gap on the right or force the last column onto a line of its own, and the second outcome looks like a bug in the stacking rules when it is arithmetic.
Gutters and padding come out of the content, not out of the row
This is the setting that most often produces a result nobody intended. The gap between columns, and the padding inside each column, are subtracted from the space the content had. A fifty-fifty row with generous padding on both columns leaves each piece of content noticeably narrower than half the row, and an image sized to look right at half width now sits in a column that is meaningfully smaller.
The practical rule: set the row’s width first, then the column shares, and add padding last, checking the content after each change rather than at the end. When a heading breaks awkwardly across two lines, the cause is usually padding added after the type size was chosen.
Every breakpoint holds its own values
Width settings are stored per screen size. That is the feature, and it is also the trap: a value you set on desktop generally flows down to the smaller views until something overrides it, so a change made while looking at the desktop view silently rewrites the phone layout too — and a change made in a smaller view does not travel back up. what the tablet view inherits is the middle case worth understanding properly, because it is the view people check least and the one that inherits from both directions.
Two related behaviours belong to the same family and are covered separately: the order a phone puts your columns in, which is about order rather than width, and hiding an element on mobile, which is the right answer when a column has no useful narrow form at all. Reach for hiding sparingly — a column that is not worth showing on a phone is often not worth showing anywhere.
What overflows a narrow column
Most content shrinks obediently. A few things do not, and they are the usual cause of a page that scrolls sideways on a phone:
- An image or embed given an explicit pixel width rather than a percentage.
- A long unbroken string — a URL pasted as plain text, a reference number — with no space for the browser to break at.
- A table with more columns than the narrow view can carry.
- A button whose label is long enough that it cannot wrap. submit button wording and state is worth deciding with the narrowest column in mind.
- An element with a negative margin nudged into place on desktop.
Horizontal scroll on a phone is the symptom to look for, because it announces the problem without telling you which element caused it. Halve the browser width on desktop until it appears; the element that stops shrinking is the one.
Where width becomes a performance question
A column’s width determines how large the image inside it needs to be. An image uploaded at full desktop resolution and displayed in a third-width column is delivering several times the pixels anyone sees. It takes minutes to fix and it is one of the most common causes of a slow page. lazy loading funnel images helps with what is below the fold; sizing to the column helps with everything. what a page speed score measures will show the difference before and after.
a section background video deserves the same thought. It is bound to the section rather than the column, so a narrow column sitting on top of it does not reduce what is downloaded.
Structures worth reusing
Certain row shapes recur across a site: a two-column intro with an image beside text, a three-column feature strip, a full-width band with a single constrained column of copy. Build those once with the widths and padding settled and keep them, because saving a section to the library preserves the settings along with the design. It removes the most repetitive part of the work and, more usefully, stops the same layout from drifting to slightly different values on each page.
Some elements have layout opinions of their own that interact with the column around them. an accordion faq block is comfortable in a narrow column and awkward in a very wide one. a product detail page usually wants an asymmetric split rather than an even one. inline against popup form placement changes what width the form needs. a sticky header’s height and trade-offs is a reminder that vertical space is finite in the same way horizontal space is.
A quick way to check a row
- View the page at full desktop width: does the text measure stay comfortable, or does it run edge to edge?
- Drag the browser narrower and watch where the row rearranges — that is your real breakpoint, whatever the panel says.
- At the narrowest width, confirm nothing scrolls sideways.
- Check the tablet view explicitly rather than assuming it sits between the two.
- Confirm images are not being delivered far larger than the column shows.
Five minutes of that on a template row saves the same five minutes on every page built from it afterwards.
Frequently Asked Questions
Why do my columns not add up to the full row?
Because the gap between columns and the padding inside them are taken out of the space the content had. Column shares describe how the row is divided before spacing is applied, so a fifty-fifty row with generous padding gives each piece of content less than half the visible width.
Should the row be full width or constrained?
Constrain the row and let the section behind it run full width. That gives you a background reaching the browser edges with a readable text measure inside it. A full-width row is appropriate for a banner or an image strip, rarely for paragraphs.
Why does changing the desktop width change the phone layout?
Values generally cascade downward from the largest view to the smaller ones until a smaller view has its own value set. So editing on desktop rewrites everything below it that has not been overridden, while editing on mobile does not travel back up.
What causes a page to scroll sideways on a phone?
Something inside a column that will not shrink: an image or embed with a pixel width, a long unbroken string of text, a wide table, an unwrappable button label, or a negative margin set on desktop. Narrow the desktop browser until the scroll appears and the element that stops shrinking is the cause.
Is it better to set a column width in pixels or per cent?
Per cent, in almost every case. A percentage keeps its relationship to the row at every screen size, while a pixel width is correct at exactly one width and wrong at all the others. Pixels are reasonable for a fixed element such as an icon, not for a column.
How wide should the reading column be?
Wide enough to avoid constant line breaks and narrow enough that the eye finds the next line easily. Rather than chasing a number, set the row width, read a paragraph at full desktop size, and adjust until it reads comfortably on the largest monitor you support.
Do width settings copy when I reuse a section?
Yes, saving a section keeps its row and column settings along with the design, which is the main argument for building your recurring row shapes once. Check the smaller breakpoints after pasting, since the destination page may sit inside a differently constrained container.
We build your GoHighLevel account for you
CRM, pipelines, funnels, SMS and automation — configured for your business, not left for you to figure out.
- Setup (one-time)$850
- Ongoing (per month)$38.80
No obligation quote · reply within 1 business day
This site is independently operated and is not officially affiliated with, endorsed by, or sponsored by HighLevel LLC. We do not receive referral commissions — this is our own flat-fee implementation service.