Local Files, Explained for Writers
Published · Last updated
A "local file" is just a file that sits on the machine in front of you, the same category of object as a photo or a spreadsheet, except this one happens to hold a novel. That sounds obvious written down.
It's worth writing down anyway, because most writing apps go out of their way to hide whether a local file exists at all, and a manuscript is exactly the kind of thing you want to be able to point at, on the days you're not writing and just want to know it's still there.
What a file actually is, underneath the app
A document can be a file you find in your file manager, like a .docx file or a .scriv project folder: a named block of data sitting in a folder on a disk, with a size, a location, and a modification date you can check without opening it. A web app can keep it in the browser's own storage instead, which the browser writes to disk somewhere, but not as one file you can find. Scrin keeps your manuscript that way, on your own machine.
A writing app is a program that reads and writes to that file. Some apps make the file easy to find, visible in your own file manager under a name you chose, with an extension that says plainly what kind of file it is.
Others keep it inside a private folder the app controls, technically still a file on your disk, but hidden well enough that most people never see it and couldn't locate it if asked to.
Neither approach is automatically wrong on its own. The difference only tends to matter on the one day you need that file directly and the app that normally opens it isn't available, or isn't there anymore at all.
The backup you can actually see
There's a real difference between a backup that exists and a backup you can verify exists. An automatic system running somewhere on a server is a backup in name, but you can't look at it, can't count its files, can't check its date without logging into something and trusting what the screen tells you.
A local file behaves differently: you can open your file manager right now, find it, check when it last changed, and copy it to a USB drive yourself if you want a second copy under your own control.
Being able to see the thing that's supposed to be protecting your work is most of what actually makes it trustworthy in practice.
Why writers already do this by hand
Read enough of what writers say publicly about their tools and one pattern shows up again and again: people build their own backup rituals, without being taught to. Three copies. A USB stick.
Two different cloud services, kept in step by hand. A weekly export to a plain format, just in case. Nobody assigned this homework.
It gets built the same way most safety habits do, after losing something once and deciding never again, and then maintained by hand for years afterward, without anyone else ever noticing the effort.
That instinct is sound. It's also a lot of ongoing, unpaid work for something a tool could be doing in the background instead, reliably enough that the ritual could finally be allowed to stop.
A quick way to find yours
On most computers this takes under a minute. Open the file manager that came with your machine, not the app you write in, and search for the manuscript's title or a distinctive phrase from a recent chapter.
If a file turns up with a sensible name and a recent date, that's your local copy, and it's worth noting where it lives.
If nothing turns up at all, search instead for the writing app's own name; sometimes the file exists but sits buried three folders deep in a place designed for the app's convenience rather than yours.
A writing app that runs in the browser keeps the book in the browser's own storage, which this search won't show. There, the file to look for is an export, or a daily copy you downloaded from the app.
Why a plain-text copy earns its place
Among all the things a local setup can offer, one habit does more for less effort than the rest: a daily copy written in plain text, sitting next to whatever else you're using, in a format that needs nothing special to open.
Not the working file itself, which might depend on a particular app to make full sense of. A separate, dumb, readable copy, refreshed automatically, that would still make sense to you or to anyone else even if every piece of software involved in writing it disappeared tomorrow.
It's the writing equivalent of a spare key left with a neighbor: rarely needed, and exactly the thing you're glad exists on the one day it is.
What to check for yourself
Open your file manager and look for a document with today's date on it, in a location you chose or at least recognize. If you find one, you already have a visible local file, which is most of the battle.
Check, too, whether it opens in something other than the app that made it: a real text file will, a proprietary one usually won't.
If nothing turns up at all, that's worth noting rather than worrying about: it may mean your current setup keeps everything on the other side of a login screen, or in a browser's own storage, where the file manager doesn't look (Scrin keeps it there, with nothing to log into), and it might be worth asking, calmly, where your words actually are the next time you're not writing.
How Scrin does it
Your manuscript stays on your own machine, in your browser's own storage. Every window you open on it stays in step. Until you pair a second device, ask for a map or make a reading link, nothing you write leaves this device; Scrin records what you do with the application, never a word of what you write, and you can switch that off. Each day you open Scrin, it makes a plain-text copy of your manuscript (a zip of Markdown files, readable without Scrin) and brings it up to date when you leave; the last 7 stay in this browser, and some browsers can't keep one. Two things put a book out of any browser's reach: an export on your disk, and a paired second device, so download a copy, or export, to keep it somewhere else.