YouTube Row Fixer puts the videos-per-row slider back on YouTube

One setting, and the layout YouTube took away

The repository description is the whole scope: a browser extension for customizing the videos per row, and making YouTube great again. The README puts it more precisely, a browser extension that lets you customize the number of videos, posts and shorts displayed per row on YouTube.

That is a genuinely small feature, and it is worth being clear that the project is not trying to be more than that. YouTube historically let users pick the grid density, then removed the control, and the layout became whatever the algorithm decided. The extension puts that choice back, and the README's own framing of it, which mentions making YouTube great again, is a joke about the size of the change relative to the annoyance.

Three things are covered: the number of videos in a row, the number of posts in a row, and the number of Shorts in a row. Those are three separate surfaces in the YouTube interface, so the extension is not doing one thing three times, it is applying the same idea in three places.

The project is JavaScript, MIT licensed, with the `main` branch, and it is published in the Chrome Web Store under the name YouTube Row Fixer. The repository topics list chrome-extension, extension, firefox-addon, youtube, youtube-videos-per-row-fix and yt-row-fixer.

The release history gives you the current state. The tags are v1.1.8 from 2026-04-13, v1.1.7 from 2025-11-24 and v1.1.6 from 2025-09-01, and the last push to the repository was on 2026-04-13. That date matters more here than it would for most projects, because an extension that patches a web page depends on the page staying the same.

Installing means going to a store, not a build step

The installation section of the README is two links and one note.

The Chrome listing is the primary route, with the extension available from the Chrome Web Store. The second entry is a Firefox extension on addons.mozilla.org, and it is annotated as coming soon. The README links it anyway, so the listing exists but the project treats the Firefox path as not yet ready.

There is also a third option that the README deliberately keeps disabled. A userscript on Greasy Fork exists for the same tool, but the line is commented out in the source of the README with the reason given in the comment itself, that it is not recommended because the author is too lazy to update it. That is an unusually honest thing to leave in a README, and it also tells you the userscript exists but is stale, so a Greasy Fork user would be running an old version.

The practical consequence is that this is an extension you install from a store, not something you build. There is no packaging step for a user, and no developer mode toggle to enable.

For contributors, the README points at `CONTRIBUTING.md` rather than describing the workflow inline, so the specifics of how to build and submit are in that file.

The README also carries a support section pointing at a Ko-fi link, and a credit section, so the project is maintained by an individual and accepts tips.

The build pipeline mixes Next.js, Vite and Webpack

The package manifest is where this project gets interesting, because the tooling is layered in a way that needs explaining.

The package is named `nextjs-crxjs-chrome-extension` and marked private, so it is not published to npm. The scripts are:

  "scripts": {
    "dev": "vite",
    "test": "webpack",
    "build": "next lint && next build && next export -o build && webpack --mode production && node utils/build.js",
    "zip": "node utils/zip.js",
    "prettier": "prettier --write src/**/*.{js,jsx,ts,tsx,css,scss}"
  },

The build script shows the three-tool pipeline. Next.js lints, builds and exports to a `build` directory, Webpack then runs in production mode over the extension, and a Node script at `utils/build.js` finishes the job. The `zip` script calls `utils/zip.js`, which is presumably what packages the result for upload to the store.

The dependency list explains why each tool is there. Next.js is pinned at 12.1.6 with React 18.2.0, and the `@crxjs/vite-plugin` at 1.0.14 is what builds a Chrome extension from a Vite project, with Vite itself at 2.9.18. So the extension's JavaScript goes through Vite and the crxjs plugin, while Next.js handles the options interface, which is a separate page built with React.

That split is the design: the options UI is a React app with Tailwind 3.4.3, `next-themes` for light and dark, `framer-motion` for animation, `react-icons` for the icon set and `@nextui-org/react` for components. The content script side is the part that runs on YouTube itself.

The repository layout follows the same split, with `src/` for the application source, `extension/` for the extension manifest and its pieces, `public/` for static assets, `utils/` for the build scripts, `index.html` at the root for the Vite side, `next.config.mjs` for the Next side, and `vite.config.js` and `webpack.config.js` for the two bundlers. There is also `jsconfig.json` rather than a TypeScript config, `tailwind.config.js`, `postcss.config.js`, `.babelrc` and `.eslintrc.json`.

A note on the `test` script, because it is a common source of confusion in extensions: `test` runs webpack. There is no test framework in the dependency list. So the repository has a build verification step and no automated tests.

Why a page-patching extension is a fragile thing

The honest limitation of this project is not in its code, it is in its dependency.

YouTube's layout is not a documented API. It is the result of a continuous series of frontend changes, and an extension that changes the number of items per row has to find the right containers in the page and rewrite the grid rules. When YouTube redesigns, the selectors move, and the extension either stops working or, worse, keeps working but lays the page out wrongly.

There is a second failure mode that is specific to YouTube, and it is the reason the last push date is the most useful fact in the metadata. YouTube ships its frontend continuously, so a change can reach users at any time without a version bump of anything the extension depends on. There is no compatibility table to consult and no changelog on YouTube's side to read. The extension author finds out from bug reports.

That makes the release dates the practical guide. v1.1.8 came out on 2026-04-13, and the previous release was v1.1.7 on 2025-11-24, so there is a pattern of shipping when something breaks rather than on a schedule. Given that the last push was also on 2026-04-13, the state of the code today is what shipped in April, and whether it still works against the current YouTube is something the project cannot tell you from its README.

There is also the category question. Any extension that rewrites a page you visit constantly is running on every page load, on a site you log into, with your watch history and your account cookies in scope. The MIT licence and the store listing tell you the code is open and the distribution is through the usual review process, and `SECURITY.md` in the repository root indicates the project has thought about reporting issues at least to the level of having a policy file for it.

For a user who wants three videos per row instead of four, that is a reasonable trade. For a user who handles an account with real consequences, it is worth reading the source of the content script before installing.

The alternative is a userscript, and the project already tried it

There is a direct alternative for this exact job, and the repository contains a pointer to it. The Greasy Fork userscript for YouTube videos per row fix exists, and the README links it while keeping it commented out of the installation list.

The difference in approach between the two is the packaging and the maintenance contract. A userscript is a single file you paste into a script manager, it runs in the page, and it updates whenever its author pushes an update to Greasy Fork. A browser extension is an installed application with a manifest, a packaged bundle and a store listing, so it gets the browser's own update mechanism and the store's review, and it has more surface area to break when the browser changes.

The project's own reason for not recommending the userscript is maintenance capacity rather than a technical flaw. The commented-out line says it is not recommended because the author is too lazy to update it. That is worth taking at face value: the userscript still exists for anyone who wants it, but it is not being kept current.

There is a third route, and it is the one to weigh before installing anything. If you want a denser grid on YouTube, you can change it with a user stylesheet or a custom CSS rule in a userstyle manager, setting the grid template columns on YouTube's own container. That approach has the same fragility as the extension, since it depends on YouTube's class names, but it keeps the change in your hands as a readable rule, and it does not require granting an extension the ability to run scripts on every site you visit.

So the real comparison is not between two extensions. It is between a packaged, store-reviewed extension that will be updated when its author reacts to a YouTube change, and a CSS rule you maintain yourself and that breaks at the same moment.

What the repository contains beyond the extension

A few entries in the top level are worth naming, because they describe what kind of project this is.

There is a `CHANGELOG.md`, which for an extension of this size is the file to read first if you are deciding whether a current version exists. There is a `SECURITY.md`, a `CONTRIBUTING.md` and a `LICENSE`.

The `.github/` directory suggests the release process is at least partly automated, and the combination of `utils/build.js` and `utils/zip.js` with a package script for each indicates that the packaging step is scripted rather than done by hand, which is what you would expect for a project that has shipped more than a dozen releases.

The `extension/` directory at the top level, alongside `src/`, is the part that distinguishes this from a plain web app. It holds the extension manifest and the pieces that the browser needs to know about, such as what permissions are requested and when the content script is injected. Since the extension's job is to change the layout of YouTube pages you visit, the permissions it requests are directly tied to that scope, and the manifest file is the place to check that.

The `public/` directory holds static assets, and `next.config.mjs` sits beside `vite.config.js` and `webpack.config.js`, which is the clearest evidence of the three-stage pipeline described in the build script. `index.html` at the root is the Vite entry point, and the `jsconfig.json` rather than `tsconfig.json` tells you the project is plain JavaScript with editor hints, not TypeScript, despite the `prettier` script formatting `ts` and `tsx` files as well.

The overall picture is a small, single maintainer project with a real build pipeline and no test suite, shipping a focused feature to two browser stores.

Editorial conclusion

Adopt YouTube Row Fixer if you want a different grid density on YouTube and are willing to install an extension that keeps rewriting the page layout on every visit. Do not adopt it expecting a cross-browser tool, since the Firefox listing is marked as coming soon in the README, and do not adopt it if you need features beyond the row count. Verify first that the current YouTube page structure still matches what the extension expects, since the last push was on 2026-04-13 and the most recent release is v1.1.8 from the same day, and that the layout still looks right after a YouTube redesign, because that is when an extension like this breaks silently.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. sapondanaisriwan/youtube-row-fixer on GitHub