# Removing inline styles from hundreds of PrestaShop product pages without breaking the layout

> Everything looks fine on desktop while the mobile rendering degrades. The seven-step procedure, from prior measurement to final check, and the four situations that go wrong with their fix.

- Page: <https://www.datafirefly.com/en/2026/10/01/remove-inline-styles-prestashop-products/>
- Language: en
- Published: 2026-10-01
- Last updated: 2026-10-01
- Other languages: [fr](https://www.datafirefly.com/2026/10/01/supprimer-styles-inline-fiches-prestashop/index.md), [es](https://www.datafirefly.com/es/2026/10/01/eliminar-estilos-inline-fichas-prestashop/index.md), [de](https://www.datafirefly.com/de/2026/10/01/inline-styles-prestashop-produktseiten-entfernen/index.md), [it](https://www.datafirefly.com/it/2026/10/01/rimuovere-stili-inline-schede-prestashop/index.md), [pl](https://www.datafirefly.com/pl/2026/10/01/usuwanie-stylow-inline-karty-prestashop/index.md), [nl](https://www.datafirefly.com/nl/2026/10/01/inline-stijlen-verwijderen-productpaginas-prestashop/index.md), [pt](https://www.datafirefly.com/pt/2026/10/01/remover-estilos-inline-fichas-prestashop/index.md)
- Index: <https://www.datafirefly.com/en/2026/llms.txt>

Styles written directly into the code of product pages are a silent problem: everything looks fine on desktop, and the mobile rendering degrades without anyone noticing. Removing them in bulk is a simple operation, provided you know what it covers and how to check the result.

This article covers the execution procedure. The reasons for running this project and what a word processor really injects have been detailed separately.

## Step 1: measure the scale

Before processing, count. Three readings to take on the database.

**The number of pages concerned**, that is, those whose description contains a style attribute. On a never-cleaned catalog, the proportion frequently exceeds half.

**The average weight of the descriptions**, with and without styles. Compare the field length before and after a simulated cleanup on a few rows.

**The heaviest pages**, sorted by decreasing description length. The top twenty often concentrate the most pathological cases and they are the ones to examine first.

This count is done on the long and short description fields, in the product description table, with a join on the language. Remember to handle each language, as the problems are not identical from one translation to another.

## Step 2: identify the patterns present

Not all styles look alike and not all are handled the same way.

Extract a sample of twenty descriptions among the heaviest and look at the code. You will generally find four families.

**Font and size declarations**, repeated on every paragraph. Remove without hesitation.

**Text and background colours.** Careful: some are intentional, notably on info boxes or warning notices. Look before removing everything.

**Fixed widths and heights**, on tables or images. They are the ones that break the mobile rendering, and their removal requires a visual check.

**Alignments and margins.** Generally removable, except on deliberate layouts.

This sample reading takes half an hour and it determines the exact scope of your processing. Without it, you apply a uniform rule to different situations.

## Step 3: back up, really

Three precautions, and the third is the one people forget.

**A complete database export**, tested. A backup file you have never tried to restore is not a backup.

**A copy of the description table**, duplicated before processing. It allows a targeted restore without touching the rest of the database, which is much faster than a full restore.

**Keeping the copy for several weeks.** A rendering problem on a rarely visited page may only be reported a month later.

## Step 4: process a sample

It is the step that avoids bad surprises, and it is often skipped.

Select twenty representative pages, making sure to include the difficult cases: one page with a specification table, one with embedded images, one with a long list, one with a coloured info box, and one among the heaviest of the catalog.

Apply the processing on these twenty pages only, then compare visually before and after, on desktop and on mobile.

Three questions to ask on each page. Is the structure preserved, headings, lists, tables? Has an intentional formatting disappeared? Is the mobile rendering better than before?

If the answer to the second question is yes on more than one page, adjust your rules before continuing.

## Step 5: process in batches

Four principles.

**One category at a time**, starting with the one with the fewest references, to run in the process.

**One language at a time**, or all together if your rules are identical, but with a check per language.

**A record of what has been processed**, with the date and the scope. It lets you know what remains and roll back in a targeted way.

**A check after each batch**, on five pages drawn at random from the batch. Five minutes per batch, and it avoids discovering a problem after processing three thousand products.

A practical point: on a large catalog, process outside traffic hours. A massive update of the description table produces locks and can slow the site down.

## Step 6: clear the caches

A short and systematically forgotten step, which explains most of the "the cleanup changed nothing".

Three caches to handle. PrestaShop's **application cache**, which keeps product data. The **page cache**, if active, which serves pre-generated full pages. And the **browser cache** during your checks, by testing in private browsing.

Add a fourth if you use an upstream delivery service, whose cache must be purged for visitors to see the new content.

## Step 7: check the result

Five checks, one week after the complete processing.

**The average weight of the descriptions**, compared with the initial reading. A 60 to 80% reduction is common.

**The rendering of twenty pages on mobile**, drawn at random from different categories.

**The pages with tables**, specifically, which are the most exposed.

**The loading time** of a typical page, before and after.

**Customer service reports** on display issues, which surface the cases you did not see.

## What can go wrong

Four situations, with their fix.

**A table that became unreadable.** The column widths disappeared and the content spreads badly. The fix goes through a style rule in the theme, applied to all description tables, rather than a restore.

**A warning box that became invisible.** Its background colour was removed. Restore it with a class rather than a style written in the content.

**Distorted images.** Their fixed dimensions are gone. A global style rule on description images, with a relative maximum width, settles the case and incidentally improves the mobile rendering.

**A deliberate layout lost.** On a few carefully crafted pages, the cleanup erased real work. That is the case where the targeted restore from the table copy is justified.

These four situations have one thing in common: the right answer is almost always a rule in the theme, not a return to the style written in the content.

## Not redoing the project in six months

Three measures after cleanup.

**Configure the editor** of the back office to filter pasted content.

**Train the people who enter content** on pasting without formatting, which is a keyboard shortcut and nothing more.

**Process at import** if your descriptions come from a supplier file, applying the cleanup at integration time rather than after.

The  industrialises this procedure on PrestaShop 8 and 9: detection of the pages concerned with a prior count, preview before application, batch processing with an operations log, and automatic filtering of content pasted into the editor.