Most people find my video downloader on their phone. They tap a link in TikTok or Instagram, land on the page, paste a link, and want the file. If the page is awkward on a small screen, they leave.

So I build the mobile layout first, and the desktop layout second. It changed how I write CSS for the whole site.

Start with the smallest screen, not the desktop

The old way I used to work was to build the full desktop page, then add media queries to squeeze it down. That meant every fix was a patch on a layout that was never designed for a phone: buttons too small, the input too narrow, horizontal scroll from one element a few pixels too wide.

Now the base stylesheet is the mobile stylesheet. The body is a single column, full width, with generous padding. The input field and the download button are both full width and stacked, because on a phone that is the only arrangement that makes sense. Text reads without zooming, and tap targets are big enough for a thumb, not a mouse pointer.

Then I add one media query, usually at around 640 pixels, for wider screens. That query turns the single column into a centred container with a maximum width, and puts the input and the button side by side. One breakpoint, not five.

One job means one column

A tool page is not a blog and it is not a dashboard. It has one job: take a link, give a file back. So I resist the urge to add a sidebar, a feature grid, or a row of cards above the fold. On mobile, every one of those pushes the actual tool further down the page, and that is the difference between a visitor using it and a visitor leaving.

The layout order on mobile is deliberate: a short heading, the input and button, then the result area, then everything else — the how-it-works steps, the FAQ, the footer links. The visitor sees the tool first and the explanation second. On desktop the same order stays, just centred. I do not rearrange anything between screen sizes — rearranging is where layout bugs hide.

The bugs that only show up on a real phone

A few things I only caught by testing on an actual phone, not a resized desktop browser:

  • Horizontal scroll from one element. A long URL in a result line, or a wide button, can push the page wider than the screen. Setting overflow-wrap: anywhere on result text and max-width: 100% on buttons and images fixed it.
  • The keyboard covering the button. When the visitor taps the input, the phone keyboard slides up. If the download button sits below the fold, they have to dismiss the keyboard to reach it. Keeping input and button close together, near the top, avoids that.
  • Tap targets that look fine but feel wrong. A 32-pixel button looks fine in a screenshot. Under a thumb it is fiddly. I aim for at least 44 pixels of height on anything tappable.
  • Tables that overflow. A few small tables on my calculator pages used to clip on a phone. Wrapping them in a container with overflow-x: auto lets the table scroll inside its own box instead of breaking the page.

Keep the CSS small

The whole site ships no frameworks and no webfonts. The stylesheet for a tool page is one small file, written by hand. That is deliberate: on a phone over a slow connection, every kilobyte matters.

When something looks wrong on a phone, I can read the file and find the rule in seconds.

The rule I keep

If a change looks good on desktop but I have not checked it on a phone, it is not finished. The phone is where the visitors are, so the phone is where the page has to work.

I build my downloader, ramrom.io, this way — one column, one breakpoint, one small stylesheet — and it is the least stressful CSS I have ever written.