How Much RAM a Clipboard Manager Should Use

A clipboard manager should use as much RAM as it needs to do its job, and not one byte more. The problem is that "its job" varies wildly. Win+V stores 25 items of up to 4 MB each — 100 MB worst case, but typically 5–10 MB of resident data. Ditto stores thousands of items in a SQLite database on disk and keeps a small cache in RAM. CopyQ does the same with a richer in-memory model for its editing and scripting surface. An Electron-based shelf like Edge-Drop ships a complete Chromium renderer process whether the shelf is open or not. The result is a RAM range from roughly 5 MB to roughly 160 MB for tools that are functionally similar. This teardown covers where the RAM goes, when the extra RAM buys a real feature, and when it does not.

For neighbouring topics, see laptop battery and always-on clipboard polling, CPU spikes when you copy a huge image, clipboard tools on multi-monitor Windows setups, and ultrawide screens and modal-clipboard popups.

The RAM range, in plain numbers

A clipboard manager on Windows in 2026 lands in one of four RAM tiers. The numbers below are typical idle footprints as reported by Task Manager, not lab-measured values. Real footprints vary with how many items the manager has stored, how many formats it captures per item, and whether it is currently rendering previews.

The gap between the native tier and the Electron tier is roughly 10–30x. That gap is the central fact of this teardown, and the reason the question "how much RAM should a clipboard manager use" does not have a single answer. The honest answer is "as little as possible, given the features you need." The rest of this article unpacks what that means in practice.

Where RAM goes in a native clipboard manager

A native clipboard manager (Ditto, ArsClip, ClipboardFusion) is a small C++ or Delphi executable that uses the Win32 API directly. The RAM footprint is dominated by four things.

• The executable itself. A few megabytes of code, loaded once at startup.
• The in-memory item cache. Most native managers keep the last few dozen items in RAM for fast access, with older items paged out to a SQLite or proprietary database on disk. A cache of 50 items at 2 KB average is 100 KB — trivial.
• The UI toolkit. Ditto uses the Win32 native controls; ArsClip uses Delphi's VCL; ClipboardFusion uses .NET WinForms. Each of these is a few megabytes of shared libraries.
• Thumbnail and preview bitmaps. This is where native managers can balloon. A manager that caches a thumbnail for every bitmap in history can use 1–2 MB per thumbnail if the thumbnails are large. Most native managers cap thumbnail size at 64x64 or 128x128 and keep thumbnails for only the most recent items.

The total is small because the toolkit is shared with the OS, the storage is on disk, and the in-memory cache is bounded. A native manager can run all day on a 4 GB laptop without measurable impact.

Where RAM goes in an Electron clipboard manager

An Electron-based clipboard manager (Edge-Drop, EcoPaste, some others) pays for the entire Chromium runtime whether it uses it or not. The footprint is dominated by four things, in roughly decreasing order of size.

• The Chromium renderer process. This is the V8 JavaScript engine, Blink layout engine, and the supporting GPU process. A minimal Electron app starts at around 80–100 MB of resident RAM before any application code runs.
• The application's JavaScript bundle. React, Zustand, Framer Motion, the app's own code. A typical mid-size React app is 5–15 MB of parsed JavaScript in memory.
• The cached UI state. React component trees, Framer Motion animation states, the in-memory clipboard model. For a clipboard shelf with 25 items visible, this is a few megabytes.
• The on-disk payloads for large items. Electron apps that handle large clipboard payloads (images, files) typically offload them to disk and load on demand. Edge-Drop does this via its edgelocal:// scheme for image thumbnails. The offload keeps the resident RAM bounded, but the offloaded payloads still live on disk and have to be loaded into RAM when viewed.

The total is 130–160 MB typical for Edge-Drop. This is not a bug; it is the cost of using Electron. The same Electron app re-written in native C++ would use 10–20 MB. The trade-off is development velocity (Electron's web-stack UI is much faster to build and iterate) versus runtime cost (Chromium is heavy).

For a deeper comparison of Electron versus native for overlay utilities, see Electron versus Tauri for overlay utilities. For the Edge-Drop-vs-Ditto RAM comparison specifically, see Edge-Drop vs Ditto: hover shelf or tray history.

When the extra RAM buys a real feature

The Electron tier is not paying for nothing. The extra 100+ MB buys features that are genuinely hard to build in a native tool, and that justify the cost for some users.

• A modern, animated UI. Framer Motion lets the shelf slide, fade, and react to hover with spring physics. A native manager can do this, but it takes significantly more code, and the result is usually less smooth. For a tool whose primary interaction is hover, the smoothness matters.
• Cross-platform UI code. Electron apps share UI code between Windows, macOS, and Linux. Native managers are per-platform. Edge-Drop is Windows-only, but the choice of Electron was made for development-velocity reasons that are valid even on a single platform.
• Drag-out via OLE / startDrag. This is the feature that distinguishes Edge-Drop from a tray manager. A native tray manager can paste; it cannot easily drag a real file into Photoshop or Slack with proper OS file handles. Electron's startDrag API exposes the OLE drag-out mechanism in JavaScript, which is why Edge-Drop can drag a file from its shelf into Explorer with a real file handle, not a fake HTML5 drag. Replicating this in a native tool is possible but non-trivial.
• Click-to-paste without focus stealing. The WS_EX_NOACTIVATE window style plus Electron's input routing lets Edge-Drop paste into the previously focused app without stealing focus. A native manager can do this with SendInput, but the coordination between the shelf's UI and the target app's input is easier in a single-process Electron app.

The honest summary: the extra RAM buys a hover-activated shelf with smooth animation, drag-out to any app, and click-to-paste. None of those are things Win+V or Ditto does well. For users who want those features, the 130–160 MB is a fair price. For users who do not, it is wasted RAM.

When the extra RAM does not buy anything

For some users, the Electron tier is strictly worse than the native tier. The cases where it does not pay:

• Low-RAM PCs. A 4 GB laptop running Windows 11 is already tight on RAM. Adding 150 MB for a clipboard manager is 3–4% of total RAM, which can be the difference between the laptop paging to disk and not. On these machines, Ditto or Win+V is the right choice. See best clipboard manager for low-RAM PCs.
• Gaming machines under load. A gaming PC running a 12 GB VRAM title may be tight on system RAM too, especially if the game is using system RAM as a fallback. A 150 MB clipboard manager is not the difference between playable and unplayable, but it is 150 MB the game could use for texture cache. Competitive players should use Win+V or Ditto during gameplay.
• Background-only use. A user who only wants clipboard history — who never drags items out, never uses hover, never needs the animated UI — gets nothing from the Electron tier that they could not get from Ditto. The native tier does history better, cheaper.
• Battery-sensitive laptops. Electron apps wake the CPU more per polling cycle than native apps, because the V8 runtime has to be woken up alongside the polling thread. See laptop battery and always-on clipboard polling for the per-wakeup cost analysis.

The honest recommendation

The recommendation depends on what the user needs from a clipboard manager, not on which tool is "best" in the abstract.

• Need nothing but history, on any machine. Win+V. Zero incremental RAM, zero polling cost, 25 items is enough for most workflows.
• Need more than 25 items, on any machine. Ditto. Native, light, configurable, free. The right default for almost everyone.
• Need scripting, rules, or automated transformations. CopyQ. Larger RAM footprint than Ditto but still native-tier; the scripting layer is the only mainstream option for "auto-redact tokens on copy" type workflows. See when CopyQ commands beat any shelf.
• Need a hover-activated shelf with drag-out to any app. Edge-Drop. The Electron cost is real; the drag-out feature is the reason to pay it. For users who spend their day dragging assets between Photoshop, Word, Slack, and Explorer, the shelf pays for itself in the first week.
• On a low-RAM PC, regardless of need. Win+V or Ditto. Do not run Electron on a 4 GB machine for clipboard history.

The same recommendation framed as a question: what does the user do with the clipboard? If the answer is "copy and paste text," Win+V or Ditto. If the answer is "drag files and images into creative apps," Edge-Drop. If the answer is "automate clipboard transformations," CopyQ. The RAM cost follows from the use case, not the other way around.

A note on "Edge-Drop is heavy"

The honest framing for Edge-Drop's RAM cost is this: it is a Chromium app, and Chromium apps use 100+ MB. This is a real objection, and the right response to it is not "but it's worth it" — it is "use Ditto if the RAM matters to you." Edge-Drop does not win on RAM. It does not win on scripting (CopyQ does). It does not win on cloud sync (no shipping cloud sync). It does not win on capture (no screenshot capture, no ShareX integration). It does not win on text expansion (no PhraseExpress-style expansions). What it does is provide a hover-activated shelf with drag-out to any app, on Windows, with fullscreen suppression and WS_EX_NOACTIVATE focus handling. If that specific combination is what the user needs, the 130–160 MB is the cost. If it is not, there is a lighter tool that does what they need.

For the broader "when not to use Edge-Drop" framing, see when not to use Edge-Drop and competing with Ditto without pretending to be Ditto.

A dedicated walkthrough is Startup Cost: Login-Item Clipboard Apps.

Related reading

• CPU Spikes When You Copy a Huge Image
• Startup Cost: Login-Item Clipboard Apps
• Clipboard Tools on Multi-Monitor Windows Setups
• Win+V Not Working on Windows 11: 9 Fixes

Sources

• Microsoft Support — Using the clipboard on Windows — official statement of Win+V's 25-item / 4 MB limits, which sets the floor for how much clipboard data any manager needs to keep resident
• Microsoft Learn — AddClipboardFormatListener function — official documentation for the clipboard listener API that determines how much polling overhead a manager pays
• Electron — Memory usage documentation — official Electron documentation on performance and memory, including why Chromium renderer processes are 80–100 MB at baseline
• Ditto — GitHub README — official documentation for Ditto's SQLite-backed storage model and the native C++ architecture that keeps its RAM footprint in the single-digit MB range
• Microsoft Learn — WS_EX_NOACTIVATE extended window style — official documentation for the no-activate window style that lets a hover shelf stay visible without stealing focus, the feature that justifies Edge-Drop's existence despite its RAM cost

Copy. Stack. Drop.

Transform your clipboard into an interactive edge shelf. Stack, pin, and drag assets into any app with zero friction.

Download for Windows Get from Microsoft Store

How to Install Guide · First 10 Minutes Guide · Drag & Drop Guide · Edge-Drop vs Win+V · Support