'Locked for editing by another user' — when no one else has the document

The first time this happened to me was at 11 PM on a Sunday. I was finishing up a client proposal due Monday morning. I'd closed the document, gone to make tea, come back, opened it again — and Word said it was locked for editing by "another user." There was no other user. It was me. In my apartment. Alone except for the cat. And the cat doesn't have a Microsoft 365 license.

I almost cried.

I didn't, because I figured it out, and now I'm going to walk you through it. Because this happens constantly, the Microsoft docs on it are useless, and the official "Open a Read-Only Copy" button is a workflow trap that loses changes. There's a real fix. Several real fixes, depending on what's actually holding the lock.

The lock isn't a person — it's a tiny file

Here's the thing nobody explains. When Word opens a document, it drops a hidden companion file in the same folder. The filename starts with ~$ followed by the original document name. So Q3-Forecast.docx gets a sidecar called ~$Q3-Forecast.docx. That tiny file — usually around 200 bytes — is what tells every other Word instance "hey, this one's busy."

If Word closes cleanly, it deletes the sidecar. Great. Done.

If Word crashes? If your laptop sleeps mid-save? If OneDrive syncs the sidecar up to the cloud before the main file (this happens more than you'd think)? If you yank a USB stick out? If your Wi-Fi drops at the wrong half-second? The sidecar gets left behind. And now anyone — including future-you, on the same machine — gets the lock warning when they try to open the file.

Find and remove the lock file directly

For a document on a local drive or a synced OneDrive folder, this is your first move:

1. In File Explorer, open the folder that contains the document.
2. View tab → tick Hidden items.
3. Look for a file called ~$YourDocument.docx (with whatever your document's actual name is).
4. Delete it.
5. Reopen the document.

Done in about thirty seconds, ninety percent of the time. If you don't see a ~$ file at all, the lock is being held somewhere else. Keep reading.

Background WINWORD processes that didn't actually quit

Closing the Word window isn't the same as exiting Word. Background WINWORD.EXE processes hang around for COM automation, Outlook attachment handling, and the dreaded preview pane in File Explorer. Any of them can hold a file open.

Open Task Manager (Ctrl+Shift+Esc). Details tab. Look for WINWORD.EXE. If you see one — or honestly, sometimes seven, I am not exaggerating — end them all. Then reopen the document.

While you're in there, also kill MSACCESS.EXE and OUTLOOK.EXE if they appear and you're not actively using them. Both of them sometimes hold Word documents open indirectly when an embedded object or attached file got previewed earlier in the session.

(I keep Task Manager pinned to my taskbar specifically because of this.)

OneDrive: the sync state matters more than you think

Document on OneDrive, or in a SharePoint library you've synced locally? The lock is split between two places. Your local sidecar file. AND the cloud's view of who has the file checked out. Either one being stuck causes the same error message.

Read the OneDrive icon

Click the OneDrive cloud icon in the system tray. Find the file. The status icon next to it is everything:

Icon	Meaning	Lock implication
Green checkmark, solid	Fully synced, available locally	Lock should match cloud state
Green checkmark, outline	Synced, online-only	Cloud is the source of truth
Blue cloud	Online-only, not downloaded	Cloud holds the lock
Blue circling arrows	Sync in progress	Wait. Don't touch.
Red X	Sync error	This is your culprit, almost always

A red X almost always means a ~$ sidecar (or the main file itself) failed to upload, and OneDrive thinks the file is mid-edit on some other device that doesn't actually exist anymore.

Force OneDrive to reconcile

Right-click the OneDrive cloud icon → Pause syncing for 2 hours → wait ten seconds → Resume. This forces a fresh handshake with the server. Often clears phantom locks.

If that fails, right-click the file in Explorer → Always keep on this device → then Free up space. That round-trip pushes the file all the way back through the sync engine and usually clears whatever was stuck. Takes a minute. Worth doing.

SharePoint check-out left in place

If the document lives in a SharePoint library that has "Require Check Out" enabled, opening the file checks it out to you, and closing Word is supposed to check it back in. Sometimes the check-in fails silently. Usually because the network blipped. Or because you closed Word with unsaved changes and clicked "Don't Save" — which closes Word but doesn't always tell SharePoint you're done.

To check from the browser:

1. Open the SharePoint library in your browser.
2. Find the file. If it has a small green arrow on the icon, it's checked out.
3. Hover, click the three dots, More, then Check In or Discard Check Out.

If the check-out is to a different account — your old work email, a service account, your former colleague who left the company eight months ago — only the site owner can override it. Skip ahead to the admin section.

The sneaky workaround: Word for the web

This is the underrated fix. The one nobody talks about. Word for the web — the browser version — does NOT honor the local ~$ sidecar. It only checks the SharePoint/OneDrive lock state.

So:

1. Right-click the file in OneDrive (web) or in the SharePoint library.
2. Open in Word for the web.
3. Type a single space, then delete it. (This forces a save, which forces a fresh lock, which often clears the stale one.)
4. Close the browser tab.
5. Wait thirty seconds. Reopen in desktop Word.

In about 70% of cases this clears whatever the desktop client thought was happening. The web client takes over the lock, then releases it cleanly when you close the browser tab. I genuinely don't know why this works. It just does.

The Office mobile trap

Modern bug, modern cause. You opened the document in the Word mobile app on your phone. Then put your phone in your pocket without closing the document. Or you opened it on your laptop, then closed the lid before Word could properly check the file back in. Either way, mobile and desktop hold on to lock state that doesn't always release on app suspension.

To check:

• iOS or Android: open the Word app. Look at the Recent list. If your document shows up with a "currently editing" hint or a little colored dot, tap it, then tap the X (top left, on iOS) to close it explicitly.
• On the laptop: I know this is annoying advice, but stop just closing the lid. Save and close documents before sleeping the device. Especially over Wi-Fi.

The WebDAV cache (the worst one to debug)

Office uses a WebDAV-style cache to talk to SharePoint. When that cache holds a stale lock token, no amount of restarting Word fixes it. You have to clear the cache.

1. Close all Office apps. All of them. Including Outlook.
2. Open Run (Win+R). Paste this: %LOCALAPPDATA%\Microsoft\Office\16.0\OfficeFileCache
3. Rename the folder to OfficeFileCache.old. Do not delete it — your queued uploads live in here, and if anything failed to sync you want them recoverable.
4. Reopen Word. The cache rebuilds itself on next open.

If you have unsaved drafts that never made it to the server, they're inside that renamed folder, in CentralTable.accdb and the GUID-named subfolders. Office will surface a recovery prompt the next time you open the related document.

This is the fix I save for last because it's the most invasive and the most annoying to undo if something goes sideways. But when nothing else works, this is usually what works.

When you have to email the admin

If literally nothing above works — the lock is held server-side and only the SharePoint site collection administrator can release it. Send them this exact message (feel free to copy-paste):

Hi — the file at [full URL] is showing as locked for editing. I've closed all my Word and OneDrive sessions on every device I have access to. Could you please:

1. Check the file's check-out state in the library and discard if needed.
2. If it's not checked out, open the SharePoint admin centre, go to the site, and clear any active lock token on the file.
3. Confirm when done so I can reopen it.

Site admins can do this from the SharePoint admin centre under Sites → the site → Files. There is no self-service version of this for non-admin users, no matter what some forum threads claim. I've seen the forum threads. They're wrong. Don't waste an hour on PowerShell scripts you found on Stack Overflow that need admin permissions you don't have.

Three habits that prevent the next one

Once you've got your document back, these three things will save you from a repeat. I do all three. I still occasionally get a lock anyway, but maybe once a quarter instead of once a week.

• Always quit Word with File → Close before sleeping a laptop. Especially on Wi-Fi that drops at suspend.
• Turn off the Explorer Preview pane for SharePoint-synced folders. The preview pane opens documents in a hidden Word instance that often never closes cleanly. View tab in Explorer → uncheck Preview pane.
• Don't edit the same file on phone and laptop within the same hour. AutoSave and mobile lock state don't always cooperate. Pick one device per session.

So basically

The "locked for editing by another user" error is almost never about another user. In rough order of frequency, the actual cause is:

1. A leftover ~$ sidecar file in the same folder. Show hidden files. Delete it.
2. A background WINWORD.EXE process. End it via Task Manager.
3. A failed SharePoint check-in. Discard or check in via the browser.
4. The OneDrive sync engine in a bad state. Pause and resume sync.
5. A stale Office file cache. Rename OfficeFileCache and let it rebuild.
6. A real server-side lock that only the site admin can clear.

Work through them in that order and you'll get your document back without losing a single edit. The "Open a Read-Only Copy" button is a last resort. Not a workflow. Don't accept it as the answer.

(My Sunday-night proposal? Turned out to be the ~$ sidecar. Took me twenty minutes to find because I didn't yet know what I was looking for. Now you do.)