Post actualizado el día octubre 28, 2026 by DeiviSanzPlay
Long screenshots stopped being a novelty years ago, but the way phones capture them keeps shifting. Between 2024 and 2026 the feature moved from a buried utility to a first-class part of the share sheet, and the rules changed: Android 14 tightened what apps can expose to the screenshot pipeline, iOS 17 and iOS 18 reworked the full-page capture flow in Safari and beyond, and OEM skins like One UI, OxygenOS and HyperOS now stitch pages on-device with noticeably better results than the crop-and-paste tools of 2022. If you last learned how to do this on a Galaxy S20, the steps you remember are probably wrong.
This piece is about what has actually changed, where the feature still fails, and how to work around the gaps. No universal three-tap recipe, because there isn’t one anymore.
The 2024–2026 shift: from gimmick to share-sheet citizen
Two structural changes explain most of the recent behavior differences.
The first is that Google made scrolling capture a system-level action rather than an app-specific one. On Pixel and stock Android builds, the capture is now triggered from the thumbnail preview that appears after a normal screenshot, and the resulting image is handed to the same editor used for markup. That sounds cosmetic, but it matters: because the stitched image passes through the standard editor, you can redact, annotate and re-crop a long capture before it ever touches the clipboard. Older implementations locked you into whatever the OEM tool produced.
The second is the partial retreat from automatic stitching. Several manufacturers have narrowed the feature to apps that render inside a scrollable framework the system recognizes. Samsung’s implementation, for instance, historically worked almost anywhere because it simulated swipe gestures during capture. Newer builds on some devices rely more on the accessibility scroll action, which produces cleaner results but refuses to run in apps that declare themselves non-scrollable, including many banking apps and DRM-protected readers. The practical consequence: the same phone model can capture a 20,000-pixel chat thread but fail silently on a three-screen insurance policy PDF.
How each major platform handles it now
Pixel and stock Android
Press the power and volume-down buttons, then tap the small «capture more» chip on the floating preview. The phone scrolls automatically until you tap stop or the page ends. The output is a single tall PNG, typically capped around 2,000–2,500 pixels in one dimension depending on the device’s memory budget.
One detail that trips people up: on Pixel devices the chip only appears for a couple of seconds. If you miss it, the preview collapses and there is no way to retroactively extend that screenshot. You have to start over.
Samsung One UI
The scroll-capture arrow sits in the toolbar of the post-capture preview. Tap it as many times as you need, or use the auto-scroll option. One UI produces some of the tallest usable captures in the market, but it also aggressively downsamples very long images, and text that looked sharp on screen can turn mushy past roughly 15 screens. For documents you intend to read later, that is a real limitation, not a nitpick.
iPhone
iOS splits the feature in two, and the split confuses a lot of people.
Inside Safari, take a normal screenshot, tap the thumbnail, and switch the tab from Screen to Full Page. You get the entire rendered document, not just what scrolled. You can mark it up and save it as a PDF to Files. This is not a stitched image; it is a re-render, which is why it stays sharp at any length and why it occasionally captures content you never scrolled to.
Outside Safari, iOS has no native scrolling capture. In third-party apps your only options are the share sheet’s print-to-PDF trick or a third-party app. That gap is the single most common complaint I hear, and it has not closed as of the iOS 18 cycle.
Xiaomi HyperOS, OnePlus OxygenOS and the rest
Most Chinese OEM skins expose a dedicated long-screenshot button in the quick settings or the capture preview. Quality varies enormously. HyperOS handles chat apps well and web views poorly. OxygenOS is the opposite in my testing: clean web page captures, occasional duplicated header rows in chat timelines. Neither behavior is documented anywhere official, which is why user forums remain the best source for a given model.
A concrete case where the feature quietly fails
Here is a scenario worth knowing about because it looks like user error but isn’t. Capturing a long conversation in WhatsApp on a phone with the system font scaled up. The scroll capture runs, produces a tall image, and the stitched result shows the same message bubble twice near the seam. This happens because the scroll action advances by a fixed pixel offset while the message list re-renders lazily, so the overlap detection has nothing reliable to match against. Reducing the font scale temporarily, or capturing in chunks of five or six screens and stitching them manually, is the workaround that actually works. Users who assume the tool is broken and go hunting for a replacement app usually waste an afternoon.
Where scrolling capture still does not work
Honest limitations, because pretending otherwise helps nobody:
- DRM-protected content. Netflix, Kindle and most streaming apps render into a secure surface. The screenshot comes back black or blank, and no scrolling tool changes that.
- Banking and identity apps. Many declare FLAG_SECURE on their windows. The system blocks capture entirely, not just the scroll extension.
- Infinite feeds. Instagram, TikTok and similar apps never signal an end to the scroll. The capture either stops at the size cap or runs until you intervene.
- Horizontally scrolling content. Carousels, comparison tables and kanban boards are not supported by any mainstream implementation. You get the vertical slice only.
- Interactive maps and canvases. WebGL and canvas-rendered content frequently produces blank bands where the GPU surface was not composited in time.
I would also flag something less obvious: on devices with aggressive memory management, a very long capture can be killed mid-stitch and leave you with a truncated file and no error message. If you routinely capture 30-screen documents, splitting the job is more reliable than trusting the tool.
File size and resolution: the numbers people ignore
A 20-screen capture at 1440 pixels wide is not a small file. Expect several megabytes for a PNG, and considerably more if the content is photographic. Most phones will offer to convert to JPEG or WebP on share, and that conversion is worth accepting for anything you plan to send by messaging app, since several clients silently recompress large PNGs and destroy text legibility in the process.
There is also a hard ceiling. Android’s capture pipeline caps the stitched bitmap to avoid out-of-memory crashes, and the exact limit varies by device RAM and by OEM. On a mid-range phone with 6 GB of RAM, very long captures may be downscaled to roughly half resolution to fit. On flagships the ceiling is higher but still exists. If you need archival-quality output of a long document, a PDF export from the browser or a desktop capture tool will always beat the phone’s stitcher.
Third-party tools: when they are worth it
The built-in tools cover most cases. They fall short in three specific situations: capturing outside Safari on iOS, capturing content that the system flags as non-scrollable but that you legitimately need, and capturing with automatic redaction.
For the first, the most dependable no-install approach is still the print-to-PDF route through the share sheet, which works in any app that supports printing and preserves text as selectable. For the second, screen-recording plus frame extraction is clumsy but effective, and it sidesteps the accessibility-scroll restriction because it captures the display buffer rather than querying the app. For the third, several dedicated screenshot utilities offer on-device text detection and blurring, though quality varies and I would not trust any of them with documents containing credentials.
What I would not recommend is installing a random «long screenshot» app from a store listing with a generic name. These frequently request accessibility permissions, which grant effectively full control over the screen, and there is no way for a user to verify what they do with that access. The system tools exist precisely to avoid that trade-off.
What to expect next
The direction of travel is clear from platform documentation and developer previews: capture is becoming a structured operation rather than a bitmap grab. Android’s screenshot APIs increasingly return content with layout metadata attached, which is what makes features like automatic redaction and text extraction possible without OCR. If that continues, the distinction between a screenshot and a document export will largely disappear, and the tall-image file will look as dated as a scanned fax.
Until then, the practical advice stands: know which of your apps will refuse, keep captures under a dozen screens where quality matters, and treat the share-sheet conversion prompt as a feature rather than an annoyance. The tool is good. It is just narrower than the marketing suggests.
Perfiles verificables: Sitio web
Publicado el 28 de October de 2026. Última revisión: 28 de October de 2026.
