Decimen Streams QR Codes at Nearly 190 KB/s Without a Network

Tom Hardware has highlighted a browser experiment that reportedly moves files between phones at nearly 190 KB/s using rapidly changing QR codes. The transfer needs no shared network, Bluetooth pairing, dedicated app, or account. One device displays the data, while the other captures it through its camera.

That combination creates the real tension. Conventional phone transfers offer much higher speeds, but they depend on radios, operating-system services, nearby-device permissions, or cloud infrastructure. Decimen Optical Transfer replaces those dependencies with an optical channel that users can see.

The project remains a proof of concept, not a direct AirDrop replacement. Its reported performance also comes from developer testing under favorable conditions. However, the experiment shows that screens and cameras can form a practical local data path when normal connectivity is unavailable, restricted, or undesirable.

Tom Hardware Puts the Optical Transfer Claim in Context

The important result is not that QR codes can hold files. It is that a browser can stream enough of them to create a usable one-way connection.

Developer bashalarmistalt released Decimen Optical Transfer as an open-source demonstration. According to the project, one browser displays an endless sequence of encoded frames. A second browser reads those frames through its camera and reconstructs the original file.

The original coverage was published on July 31, 2026. It reported approximately 128 KB/s during handheld phone-to-phone transfers. Positioning both devices securely reportedly raised the rate to about 186 KB/s.

Those figures are developer measurements, not an independent laboratory benchmark. Device position matters because movement makes autofocus hunt and blurs individual frames. The project documentation calls hand tremor the largest throughput problem.

The developer says the idea emerged while building a cached web-based music player. They wanted to move audio files between phones that were not connected to the same network. Rapidly flashing QR codes provided a channel that did not depend on either phone discovering the other.

That path carries more than a download link. The binary contents of the selected file are divided, encoded, displayed, captured, and rebuilt on the receiving device. The payload itself travels across the visible light between a screen and a camera.

The released proof of concept uses a more conservative configuration than the parent experiment. It can transmit a 512 KB image or a selectable 2 MB image. The repository describes a transfer running at 129 KB/s during a demonstration.

The higher reported ceiling came from denser QR frames, stacked codes, and an error-corrected color channel. The developer used a 120 Hz ProMotion display for those tests. Reported performance reached about 128 KB/s handheld and 186 KB/s when the devices remained stationary.

That distinction matters. The headline number describes the best result from the broader experiment, while the public proof of concept favors easier scanning. Readers should not assume every phone and browser combination will immediately reproduce 186 KB/s.

Still, even the lower rate changes how this approach should be classified. A single static QR code is usually a shortcut for opening a website or importing a small credential. Decimen turns QR into a continuous transport medium.

A 2 MB image at 129 KB/s takes roughly the time expected from a short local handoff, not an archival upload. Large videos would remain inconvenient. Documents, audio clips, configuration bundles, credentials, and emergency files fit the channel more naturally.

The project is also deliberately one-way. The receiver does not send acknowledgments, negotiate a connection, or reveal its identity to the sender. That simplifies setup, but it creates the technical problem that defines the entire system.

If a receiving camera misses one conventional numbered chunk, the sender does not know to repeat it. Decimen solves that problem with fountain coding rather than a network-style retransmission protocol.

Fountain Codes Turn Missed Frames Into Delay Instead of Failure

Decimen works because the receiver does not need every QR frame, or even the original transmission order.

The sender first divides a file into source blocks. It then generates a continuing supply of encoded blocks, with each one combining a pseudorandom subset of the source data. The receiver collects enough distinct combinations to recover the file.

This technique is known as a fountain code. The name reflects the receiver’s behavior: it can collect encoded data like drops until it has enough to reconstruct the source. It does not need a specific drop to arrive at a specific time.

Decimen uses Luby transform coding, an early practical fountain-code design. The subset for each frame is derived from its sequence number using a robust soliton distribution. The receiver reportedly needs approximately 1.15 times the original block count before recovery.

A dropped QR frame therefore costs time, not correctness. The receiver can ignore blurred, duplicated, or unreadable images and continue collecting later frames. This property makes the system well suited to an optical channel with no return path.

The project repository explains that every frame carries a 20-byte header. That header identifies the session, sequence number, block count, block size, file length, and file hash.

Self-describing frames let the receiver join an active stream after transmission has started. Restarting the sender creates a new session identifier, which tells the receiver to reset automatically. No pairing exchange is required.

The hash gives the receiving side a way to verify the reconstructed file. It does not guarantee that the sender is trustworthy, but it can detect a result that differs from the transmitted payload.

This mechanism is different from simply displaying numbered chunks in a loop. With sequential playback, missing one frame can force the receiver to wait for the entire sequence to repeat. Longer files create longer recovery delays.

Fountain coding keeps producing useful combinations instead. The sender does not need to know which symbols have arrived, and the receiver does not need to request missing ones. That removes the feedback channel normally expected in reliable transfer protocols.

The concept predates this project. The 2018 TXQR experiment also combined animated QR codes with fountain coding. Digital Bazaar’s qram library later explored LT-coded QR streams for transmitting arbitrary data through a lossy medium.

Decimen’s contribution lies in packaging the idea around current phone displays, cameras, browser APIs, and WebAssembly. WebAssembly, commonly shortened to WASM, lets browsers execute compiled code at near-native speed.

The receiver uses a WASM build of ZXing-C++, an established barcode-decoding library. Camera frames are distributed among workers, allowing multiple decoding jobs to run without blocking the main browser interface.

Busy workers can simply drop excess camera frames. On a normal sequential channel, that behavior would threaten the transfer. Here, the fountain layer absorbs those losses and lets the next readable symbols advance reconstruction.

The implementation also handles a less visible compatibility issue. JavaScript engines do not promise bit-identical approximations for every mathematical function. A small difference in the fountain distribution could make two browsers choose different source blocks for the same sequence number.

The project therefore includes a deterministic logarithm based on explicitly defined IEEE 754 operations. This keeps V8-based browsers and Safari’s JavaScriptCore aligned when they generate the same distribution.

That detail illustrates why the browser-only label should not be confused with a simple webpage trick. The page is coordinating camera capture, parallel decoding, deterministic coding, session management, and hash verification. It is effectively a transport stack built above visible images.

The result also explains why faster QR generation alone does not guarantee faster file transfer. The sender must display each frame long enough for the camera to capture a clean image. The receiver then needs enough processing capacity to decode it before its worker queue fills.

Screen refresh, camera exposure, autofocus, browser scheduling, and decoding speed all shape the final rate. Fountain coding cannot eliminate those constraints. It prevents their inevitable losses from breaking the transfer.

The Real Opponent Is Connection Setup, Not AirDrop Speed

Optical transfer loses badly on raw bandwidth, but it avoids the discovery and trust steps required by radio-based alternatives.

AirDrop, Quick Share, Bluetooth, Wi-Fi Direct, WebRTC, messaging apps, and cloud drives can all move files faster. They are the wrong performance baseline if the central problem is that two devices cannot establish a conventional path.

Apple and Google have spent years reducing the visible friction around nearby sharing. Their systems still rely on operating-system support, compatible devices, wireless radios, discovery services, and user-approved access.

A web service can use WebRTC for direct browser communication, but the peers generally need signaling before they can connect. Network policies, incompatible routes, or restrictive firewalls can complicate that process.

Decimen avoids discovery completely. The sender displays information in public view, and any compatible receiver within optical range can collect it. Neither device needs the other’s address or identity.

That model fits damaged or isolated devices. A phone may have a working display and browser even when its cellular, Wi-Fi, Bluetooth, or cable connection is unavailable. If its camera still works, it can also receive an optical stream.

Air-gapped systems provide another potential setting. An air gap separates a device from ordinary communications networks to reduce exposure. Administrators still need controlled methods for moving updates, logs, keys, or other files across that boundary.

QR streams are already used in some offline signing and security workflows because the channel is observable. A user can see when data is crossing the boundary, although visual awareness does not reveal whether the payload itself is safe.

The browser approach lowers deployment friction because it needs no dedicated installation. The user grants camera access to the receiving page, while the sender only needs a display.

That statement requires one qualification. The browser page must initially be available on the device. Decimen can be cached for later use, but first access normally needs a server, local development host, or another installation path.

Camera access also requires a secure browser context. The project uses HTTPS during development because browsers generally block getUserMedia, the camera-access interface, on insecure remote origins.

Safari creates an additional implementation challenge because it has not shipped the BarcodeDetector interface used by some browser QR tools. The relevant WebKit issue remains part of the project’s compatibility explanation.

Decimen handles that gap by bringing its own ZXing decoder through WASM. That design improves cross-browser control, but it also adds code and processing work that a native platform service might avoid.

The system offers privacy benefits in a narrow technical sense. According to the developer, file contents stay within the two browsers and do not pass through an upload server. The sender receives no information about who captured the stream.

However, optical transmission is not automatically private. Anyone with a suitable camera and clear view of the screen can attempt to receive the same data. The present channel behaves more like a visible broadcast than a confidential paired link.

Sensitive transfers would need encryption before encoding. The public documentation focuses on reliable transport and file verification, not a full identity, authorization, or key-management system.

The sender also cannot confirm that the intended recipient finished the transfer. There is no acknowledgment channel. Users must rely on visual coordination or a separate method to confirm completion.

Those limitations are acceptable for the project’s main promise. It is not trying to replace every networking stack. It creates a fallback when establishing a connection is the larger obstacle.

That distinction puts the Tom Hardware result in perspective. Nearly 190 KB/s is unremarkable beside Wi-Fi, but surprising for a permission-light optical link built from browser primitives. The experiment exchanges abundance in bandwidth for independence from network infrastructure.

What the 186 KB/s Result Does Not Prove

The peak rate is a promising engineering measurement, not evidence of dependable performance across ordinary phones and environments.

The developer identifies physical stability as a major variable. A stationary receiver reportedly approached 186 KB/s, while handheld operation remained near 128 KB/s. That gap alone shows how strongly movement affects the channel.

Autofocus can shift while a user’s hands move. Rolling shutters may capture part of one display frame and part of another. Reflections, low brightness, viewing angle, screen scaling, and ambient light can reduce contrast.

Camera and display frame rates introduce another complication. The receiver may request 60 FPS but receive only 30 FPS. The project notes that iOS can silently deliver a lower rate when applications make an ideal request.

Its workaround is to request an exact rate where supported, then inspect the camera track settings. Even that approach cannot make unsupported hardware deliver additional frames.

The proof of concept defaults to 24 transmitted frames per second. This gives each QR image at least two refresh cycles on a typical display, improving the chance that a camera captures it cleanly.

Each default frame carries 1,465 payload bytes using a version 27 QR code. Denser version 40 frames can carry 2,953 bytes in close-range phone tests, according to the repository.

A denser code is not always faster in practice. Smaller visual modules are harder for cameras to resolve, especially with movement or imperfect focus. A frame that carries twice as much data has little value if the decoder rejects it.

The sender can tune frame rate, bytes per frame, error-correction level, and display size. The receiver can adjust capture width, camera rate, and decoding-worker count. Those controls reveal that the project has not yet reduced its performance choices to a universal automatic profile.

QR error correction is set to level L, the lowest standard level, in the documented configuration. That choice leaves more room for data within each image.

The fountain code and QR error correction address different failure modes. QR correction attempts to repair corruption inside a captured symbol. The fountain layer handles symbols that were never decoded.

Decimen favors discarding bad frames and producing more fountain symbols. That choice makes sense when clean frames arrive frequently, but poor lighting might favor a different balance.

The reported rate also excludes broader workflow costs. A user still needs both pages ready, appropriate permissions, good alignment, and enough free memory to hold the reconstructed file. These steps can dominate the experience for a small transfer.

Large files pose a different problem. At 186 KB/s, transferring hundreds of megabytes remains lengthy. Sustained camera use, maximum screen brightness, and continuous decoding will consume battery and generate heat.

Browsers can suspend background work or reclaim memory under pressure. Mobile operating systems may also change camera behavior across devices and releases. A production tool would need extensive compatibility testing.

Security deserves equal caution. A correct hash confirms that received bytes match the transmitted bytes. It does not establish who created them or whether they contain malicious content.

A page offering automatic downloads must treat filenames, MIME metadata, file sizes, and reconstructed buffers as untrusted input. The project’s open-source status helps review, but it does not substitute for a formal security assessment.

The repository currently presents the code as a minimal proof of concept. Its small history and limited test population make broad reliability claims premature. The headline result has not been independently reproduced across a published device matrix.

The project also has no inherent protection against shoulder surfing. A nearby observer can record the display and decode the stream later unless the payload was encrypted beforehand.

This risk cuts both ways for air-gapped use. A visible optical channel can be easier to supervise than an invisible radio connection. It can also leak to any camera with line of sight.

The lack of pairing reduces friction because the sender does not authenticate receivers. That same property eliminates access control at the transport layer.

None of these points invalidate the experiment. They define its actual achievement. Decimen shows that browser-based optical transport can reach useful speeds under selected conditions, while leaving product reliability, automatic tuning, and secure session design unresolved.

Prior QR Projects Show Both the Opportunity and the Ceiling

Decimen belongs to a longer line of optical transfer experiments, but better phone hardware is making the old idea more practical.

Animated QR transfer has appeared in research projects, open-source libraries, cryptocurrency wallets, and air-gapped signing tools. These systems share a basic observation: a sequence of machine-readable images can carry much more data than one static symbol.

Earlier projects often used sequential chunks. That is easy to implement, but one missed symbol can delay completion until the sequence repeats. Fountain codes made the channel more tolerant of loss and out-of-order reception.

TXQR combined animated QR codes and fountain coding in Go in 2018. Digital Bazaar’s qram library used LT codes to package arbitrary data into repeating QR packets. Both established much of the conceptual foundation behind Decimen.

Other implementations abandon standard QR entirely. Libcimbar uses custom colored visual codes designed for higher optical density. Specialized formats can pack more information into a screen area, but they lose the mature recognition software surrounding standard QR.

That tradeoff matters on phones. QR decoding benefits from decades of work on detection, perspective correction, damaged symbols, and varying lighting. A custom color system must solve those problems while managing white balance and camera color processing.

RaptorQR represents another current approach. Its developer reports a 6.5 MB transfer in 36 seconds, or 183.6 KB/s, using an iPhone 16 and Safari. It combines RaptorQ coding, WASM rendering, and ZXing scanning.

RaptorQ is a standardized fountain code described in RFC 6330. Its design targets efficient recovery from packet loss with low overhead. Decimen instead documents an LT-code implementation using a robust soliton distribution.

These projects should not be treated as controlled head-to-head benchmarks. They use different payloads, code layouts, devices, frame rates, and testing conditions. Their similar rates still suggest that phone-based optical transfer has entered a practical performance range.

Community experiments also show the remaining distance from ordinary networking. Developers working on browser QR transfer have described Wi-Fi and WebRTC paths measured in megabytes per second. Optical transfer generally remains in the hundreds of kilobytes per second.

The comparison reinforces the correct opponent. This is not a bandwidth contest against local wireless sharing. It is a contest against connection failure, unavailable radios, incompatible platforms, and policies that prohibit ordinary networking.

Standards-based QR codes also give Decimen a deployment advantage. The project can rely on familiar visual markers and established decoding libraries. Users do not need special camera hardware.

Modern phones improve nearly every part of the pipeline. High-refresh displays can present more symbols. Better cameras resolve denser codes. Faster mobile processors decode more frames in parallel. Browser WASM support brings optimized native libraries into a webpage.

Those improvements explain why an old concept can produce a new result. The underlying information theory has not changed. Consumer hardware has reached a point where the complete optical pipeline can run interactively.

AI-assisted development influenced the implementation process as well. The developer says Claude Code helped build the working proof of concept. That fact is interesting, but it is secondary to the verified design choices visible in the repository.

AI did not invent fountain codes, QR recognition, WASM, or browser camera capture. It helped one developer combine those components quickly around a specific personal problem.

That pattern is becoming common in experimental software. Developers can assemble standards, libraries, and device APIs into narrow prototypes before a conventional product team would justify the work.

The resulting code still needs human review, hardware testing, threat analysis, and maintenance. Decimen’s value comes from the system it exposes, not from treating AI-generated code as automatically reliable.

Tom Hardware readers should therefore view the project as evidence of a maturing route, rather than a single isolated stunt. Multiple teams are converging on fountain-coded optical transfer because current devices can finally execute it at useful rates.

Three Signals Will Decide Whether Optical Transfer Leaves the Lab

The next test is whether Decimen can turn a favorable demonstration into repeatable behavior across phones, browsers, and real environments.

The first signal is an independent compatibility benchmark. The project needs results across recent iPhones, Android phones, tablets, and laptops, with both sending and receiving roles tested.

A useful benchmark would separate handheld and stationary operation. It should report actual camera settings, display refresh rates, distance, lighting, payload size, failed attempts, and sustained throughput.

Reproduction near 186 KB/s across several devices would strengthen the central performance claim. Large variation or frequent transfer failures would show that optical conditions still dominate the software design.

The second signal is automatic tuning. A production-ready receiver should measure its camera rate and decoding capacity, then tell the sender which density and playback speed work reliably.

Decimen currently avoids a return channel, so this coordination would require a design decision. The receiver could display a small control QR code back to the sender, or users could select a detected profile manually.

A bidirectional visual mode would add acknowledgments, flow control, and capability negotiation. It would also complicate the defining promise of a simple one-way broadcast.

The project does not need duplex transfer to remain useful. However, automatic profiles would reduce failed attempts and make performance less dependent on expert settings.

The third signal is a security model for real files. Encryption, sender authentication, payload limits, safe download handling, and clear session indicators would move the concept beyond an engineering demonstration.

Encryption should happen before fountain encoding, so recorded frames reveal no usable file data without the key. Authentication would help receivers confirm that a reconstructed payload came from the expected sender.

Those additions must preserve the channel’s main advantage. If secure setup requires accounts, cloud services, or extensive pairing, optical transfer begins recreating the dependencies it was designed to avoid.

The most convincing outcome would be optional security modes. Casual transfers could remain immediate, while sensitive workflows could use pre-shared keys or short visual verification codes.

Developers should also watch browser camera behavior. Better access to frame-rate controls and native barcode detection would reduce implementation complexity. Regressions in mobile scheduling or camera constraints could have the opposite effect.

For ordinary users, the immediate question is simpler: when would this beat an existing sharing tool? The answer is when the normal tool cannot establish a path, asks for unacceptable access, or depends on infrastructure that is absent.

That includes isolated devices, broken wireless hardware, cross-platform recovery, supervised air-gap transfers, classrooms with restricted networks, and one-to-many broadcasts from a large display.

The method remains poorly suited to large backups or routine video sharing. It also demands care around confidential data because anyone within camera range can observe an unencrypted stream.

Tom Hardware has surfaced a credible proof that phone screens and cameras can support more than links and payment tokens. The nearly 190 KB/s result now needs broader reproduction, easier tuning, and a defined security layer.

Try evaluating the idea by its intended failure case. If Wi-Fi, Bluetooth, cables, and cloud services disappeared, would a visible browser channel help you recover one important file? That answer will determine whether streaming QR codes remain an engaging experiment or become a standard emergency route between devices.