Medium hosts a lot of writing worth reading: technical tutorials, startup post-mortems, research breakdowns, long-form essays. The reading is what gets interrupted. A sign-in prompt slides up over the third paragraph. A subscription banner covers the text. A modal asks you to join before you've finished the first section.
I wrote a Medium redirect script to take that friction out of my own browsing, and I'm giving it away. It's a userscript, meaning a small piece of JavaScript that your browser runs on pages you choose, and it sends article URLs to a cleaner reader view automatically. Installing it takes about two minutes. There's no configuration and nothing to learn.
What the Medium redirect script actually does
Three things, and nothing else.
It detects article URLs. It redirects those URLs to a simplified view that drops the visual clutter. It stays quiet the rest of the time. There are no loops, no half-loaded pages, and no extra steps for you once it's installed.
How it tells an article from a profile page
Medium URLs follow predictable shapes. A profile is medium.com/@username. A tag index is medium.com/tag/something. An article is medium.com/@username/some-title-slug followed by a trailing hexadecimal ID that Medium generates for each post.
The script reads the current URL, checks it against those shapes, and only fires on the article pattern. If you're on a homepage, a tag page, or somebody's profile, nothing happens. That single check is what stops the script from misfiring, and it's why you can leave it enabled permanently instead of toggling it on and off. If you want to understand the parsing side of it, Mozilla's MDN reference for the browser URL API covers how a script pulls apart a hostname and path.
What it deliberately does not do
I set three rules for myself when I wrote it:
- No unnecessary redirects. It activates on valid article URLs only, not on every Medium page you touch.
- No broken pages or infinite loops. The redirect logic runs once and stops.
- No data collection. It doesn't track what you read, store your behavior, or talk to any external server.
It also doesn't alter article content, scrape anything, inject ads, or interact with your Medium account. It changes how a URL is opened. That's the whole scope.
Why a Tampermonkey userscript instead of a Chrome extension
A Chrome extension is a packaged bundle: a manifest file, permissions, an icon, a store listing, and a review process before anyone can install it. That overhead is worth paying when a tool needs storage, background workers, or its own interface.
A Tampermonkey userscript is one JavaScript file with a header block at the top declaring which URLs it should run on. You can open it, read all of it in under a minute, and edit it yourself. It runs on Chrome, Firefox, Edge, and Safari without being repackaged for each one. For a tool whose entire job is "check the URL, then redirect," a userscript is the honest size of the solution.
I build both. Userscripts and Tampermonkey work sit alongside Chrome extensions in my list of automation service lines, and the decision between them usually comes down to whether the tool needs to remember anything between page loads.
Installing the userscript manager and the script
You need two pieces: a userscript manager, which is the browser add-on that stores and runs userscripts, and the script itself.
The three steps
- Install the userscript manager. Tampermonkey's official download page covers Chrome, Firefox, Edge, and Safari. It's the most widely used manager and the one I test against.
- Add the script. Grab the Medium Free Use v1.0 script file and add it through the Tampermonkey dashboard. Tampermonkey will show you the script's name, version, and match rules before you confirm. Read that screen. You should read it for every userscript anyone ever hands you, including mine.
- Browse Medium normally. The script fires on its own when you land on an article.
If Chrome refuses to run it
Recent Chrome builds require Developer Mode to be switched on before a userscript manager can execute scripts. The toggle sits at the top right of chrome://extensions. Google's Chrome extension getting-started documentation explains what that mode changes. Flip it on, reload the tab, and try again.
If nothing happens on an article
Check three things in order. Confirm the script shows as enabled in the Tampermonkey dashboard. Confirm the URL is an article rather than a profile or tag page, since the script is built to ignore those. Then hard refresh with Ctrl+Shift+R, because a page served from cache may have loaded before the script had a chance to run.
Who gets the most from distraction-free reading
I built it for three groups, based on who kept complaining to me about the same thing:
- Developers and engineers who use Medium for technical write-ups, tutorials, and documentation walkthroughs, and who lose their place every time a modal interrupts a code block.
- Students and researchers working through a topic, collecting references, or trying to read six things quickly.
- Regular readers who want a clean page and don't want to be interrupted every time they open an article.
The cost of an interruption isn't the two seconds it takes to close a popup. It's the mental thread you drop while closing it. Removing the interruption entirely is worth more than making it easier to dismiss.
Terms of service and robots.txt are your decision
I'm going to be direct about this part, because most write-ups on tools like this aren't.
I'm not a lawyer, and I'm not telling you that running this script is permitted by Medium. What I can tell you is what the script does technically: it reads a URL and navigates to a different one. Whether that fits within a platform's rules is a judgment you make, using their actual terms. Medium's published terms of service is the document that governs it, and it's short enough to read properly.
The same principle applies to every automation project I take on. When a client asks me to pull data from a site, I explain what's technically possible and what the site's robots.txt file requests, using Google Search Central's documentation on robots.txt as the reference. The decision about whether to proceed belongs to the client, and I say so in writing before any work starts.
Custom browser automation built to order
This script is roughly a hundred lines of JavaScript solving one small annoyance. Most of my work is the same idea aimed at something with money attached to it: a Playwright bot that logs into a supplier portal every morning and exports the price list, a UI.Vision macro that fills a form four hundred times, a Chrome extension that adds a missing export button to a tool your team is stuck with, a pipeline that lands the results in Google Sheets or PostgreSQL on a schedule.
If you've read this far because you recognized the shape of the problem, the fix is usually a few days of work. I'm one person, I sell through Fiverr only, and I'll tell you up front if I think your idea isn't worth building.
Send me the details of your automation project, or read the rest of the DatafetchPro blog archive for more build write-ups. If you'd rather know who you're dealing with first, my background and how I work covers it.
One example of the kind of technical article this script was built for: a walkthrough on saving Selenium browser sessions with Redis and Flask, which is exactly the sort of thing worth reading without a banner over it.