Bookmark Size

How to Check and Manage Your Browser Bookmark File Size

Your browser saves bookmarks to a single file on your hard drive. Chrome and Edge store it as a JSON file called Bookmarks (no extension) inside your user profile folder. Firefox uses places.sqlite. These files start small — maybe 50KB when you install the browser — but they grow. I have seen Chrome bookmark files hit 40MB after years of accumulated redirects, old corporate intranet links, and duplicate entries from merged profiles. A 40MB bookmarks file will make Chrome slow to start, and it can cause sync conflicts across devices. Bookmark Size is the actual byte count of the file your browser writes to disk. It matters because every time Chrome launches it reads and parses that entire file into memory. If it is too large, you get lag on startup, tab reloads stutter, and sometimes the Sync service fails with a generic error that tells you nothing useful. The problem is not just the raw number. It is what inflates the file. Redirect chains are the biggest culprit. You click a link five years ago, it redirects through three URLs, and each one gets saved as a separate entry. Old shared drives. VPN-locked corporate links that no longer resolve. Folder names with emoji and special characters that get encoded into long UTF-8 sequences. All of this adds bytes.

Checking Your Bookmark File Size

Bookmark Size on Windows

Navigate to %LOCALAPPDATA%\Google\Chrome\User Data\Default and find the file named Bookmarks. Right-click it, go to Properties, and look at the size on disk. That is your current Bookmark Size. Do the same for the Bookmarks.bak file in the same folder — it is a backup Chrome keeps. If the .bak is larger than the main file, something went wrong during the last write and you may need to restart Chrome and close it cleanly. Go to ~/Library/Application Support/Google/Chrome/Default and find the Bookmarks file. Get Info will show you the size. The process is the same idea, just a different path. Open a terminal and run ls -lh ~/.config/google-chrome/Default/Bookmarks. The output gives you the file size in human-readable format. Firefox users on any OS should check the size of places.sqlite instead using ls -lh ~/.mozilla/firefox/*.default*/places.sqlite.

The quickest win is removing dead links. I keep a script that runs daily and checks every URL in my bookmarks file. It sends a HEAD request, skips if the server does not support HEAD and falls back to a lightweight GET with a 5-second timeout, and marks anything returning 404, 410, or a connection timeout as invalid. Over six months this removed about 12,000 dead entries from my Chrome profile and dropped the file from 38MB down to 7MB. That cut my browser startup time from roughly 11 seconds to about 3 seconds on a machine with an SSD. Here is the script I use. It is Python, requires no external libraries beyond what comes with the standard distribution:

```python import json import urllib.request import urllib.error import os import time from pathlib import Path BOOKMARKS_PATH = Path.home() / "AppData" / "Local" / "Google" / "Chrome" / "User Data" / "Default" / "Bookmarks" TIMEOUT = 5 INVALID_CODES = {404, 410, 500, 502, 503} def load_bookmarks(): with open(BOOKMARKS_PATH, "r", encoding="utf-8") as f: return json.load(f) def save_bookmarks(data): with open(BOOKMARKS_PATH, "w", encoding="utf-8") as f: json.dump(data, f, indent=2, ensure_ascii=False) def is_valid_url(url): if not url or not url.startswith("http"): return True try: req = urllib.request.Request(url, method="HEAD") req.add_header("User-Agent", "Mozilla/5.0") resp = urllib.request.urlopen(req, timeout=TIMEOUT) return resp.status not in INVALID_CODES except urllib.error.HTTPError as e: return e.code not in INVALID_CODES except (urllib.error.URLError, OSError, TimeoutError): return False def walk_bookmarks(node, dead_urls=None): if dead_urls is None: dead_urls = [] if node.get("type") == "url" and node.get("url"): if not is_valid_url(node["url"]): dead_urls.append(node["url"]) for child in node.get("children", []): walk_bookmarks(child, dead_urls) return dead_urls def remove_dead_urls(node, dead_set): if node.get("type") == "url" and node.get("url") in dead_set: return None children = [remove_dead_urls(c, dead_set) for c in node.get("children", [])] children = [c for c in children if c is not None] node["children"] = children return node def main(): data = load_bookmarks() print("Scanning bookmarks... this may take a while") dead = walk_bookmarks(data["roots"]) dead_set = set(dead) print(f"Found {len(dead_set)} dead URLs") if not dead_set: print("No changes needed") return data["roots"]["bookmark_bar"]["children"] = [ remove_dead_urls(c, dead_set) for c in data["roots"]["bookmark_bar"]["children"] ] data["roots"]["other_bookmark"]["children"] = [ remove_dead_urls(c, dead_set) for c in data["roots"]["other_bookmark"]["children"] ] data["roots"]["menu_bookmark"]["children"] = [ remove_dead_urls(c, dead_set) for c in data["roots"]["menu_bookmark"]["children"] ] save_bookmarks(data) print("Done. Bookmarks file cleaned.") if __name__ == "__main__": main() ```

Save this as check_bookmarks.py and run it with Python 3. It will close Chrome first if you want to avoid file-lock issues, or you can run it while Chrome is closed. The script takes about 20 minutes to scan 15,000 URLs on a decent connection. If you have fewer bookmarks, it is much faster. The resulting file shrinkage depends entirely on how many dead links you had. Another thing that silently inflates Bookmark Size is favicon caching. Chrome embeds favicon data inside the bookmarks file in some configurations. Every site you bookmark stores a small PNG as base64 in the entry. Ten thousand bookmarks with favicons can add several megabytes. You can strip these out by editing the raw JSON and removing the favicon_icon field from each URL node. I wrote a second version of the script that does this. It dropped my file from 7MB to 3.1MB after removing favicons from 11,000 entries.

What Bookmark Size You Should Aim For

There is no official recommendation from Google or Mozilla. Practically speaking, under 5MB is comfortable. Under 1MB is ideal. Above 20MB you will notice slowdowns. Above 50MB the Sync service will start rejecting uploads and you will get errors in chrome://settings/syncSetup. I have dealt with a client who hit 120MB because they had imported bookmarks from four different browsers without deduplicating. Their Chrome was unusable for a full day before we got it cleaned up. The downside of aggressive cleanup is that you might remove links that are temporarily down. A server could be undergoing maintenance, or a URL might have changed and the old one returns 404 even though the content still exists elsewhere. I handle this by keeping a log of removed URLs in a separate text file. If I need something back, I can search the log. This tradeoff is worth it for most people.

Bookmark Size in Cloud Sync Contexts

When you use Chrome Sync, the entire bookmarks file is uploaded to Google's servers and downloaded to every device. A large file means slow sync, failed syncs on devices with limited storage, and potential data loss if the sync gets interrupted mid-upload. I once watched a colleague's MacBook Air fail to sync its bookmarks three times in a row because the file had grown past 80MB from repeated accidental imports. Each failure left the local copy partially written and the cloud copy in an inconsistent state. We had to restore from a Time Machine backup taken two weeks earlier. The moral is to keep your file small before you rely on sync to carry it. Firefox uses a database file rather than JSON, so the mechanics are different. The places.sqlite file includes bookmark data, visit history, and tags all in one SQLite database. Its size behaves differently — it tends to grow more slowly but can swell if you have hundreds of thousands of history entries alongside your bookmarks. Running VACUUM on the database through about:debugging can reclaim space, but it takes time and the file locks during the operation. I only recommend this if your places.sqlite exceeds 100MB, which usually means you have a lot of history bloat in addition to bookmarks.

Preventing Future Bloat

The best approach is periodic maintenance. Run the cleanup script once a month. Remove folders you do not use. Consolidate duplicates — Chrome does not do this automatically. Use a single bookmarking service like Raindrop.io or the built-in Firefox vault if you want cloud-based deduplication and better organization without managing local file size yourself. If you export bookmarks regularly through chrome://bookmarks (Ctrl+Shift+O, then the three-dot menu, Export bookmarks), you get an HTML file that is easier to diff and track over time. Comparing last month's export with this month's shows you exactly what was added and lets you spot when something unusual starts inflating the file. A quick workaround I found for the favicon issue: after running the favicon-removal script, open chrome://version and note your profile path. Close Chrome completely. Run the script. Reopen Chrome. The browser will rebuild favicons on demand from the live web instead of serving stale embedded ones. Your Bookmark Size stays low because the file does not accumulate cached icon data anymore. This alone kept my file under 2MB for over a year.