Comparison and literal merge
Compare complete sources before choosing a merge
Compare text and code without executing it, positional JSON or root-array records by an exact string key. Resolve literal Base / Left / Right conflicts explicitly. Original inputs and complete downloads stay in the browser workspace.
Separate private workspace. Choose exact comparison rules and review every literal merge conflict before exporting.
Choose exact comparison rules
Two to eight complete sources compare against source1. Text/code supports lines, words or code points, explicit whitespace, Unicode normalization, case and newline rules. Original equality and equality under selected rules remain different facts. These rules do not establish code, translation or legal equivalence. Structural JSON uses positional arrays, unordered object members and exact symbolic decimal value or exact number-token equality; duplicate or invalid source JSON refuses.
Match root arrays by a string key
Each complete root-array object must have the selected direct string member; empty names and string values are allowed. Missing, non-string or duplicate keys refuse the whole comparison. Dots and slashes are literal member-name characters, not paths. Nested arrays stay positional. A changed-index event records correspondence, not the author’s intention to move a record.
Resolve a literal merge
Three exact sources use the retained literal-line-atom prefix/suffix LCS policy. Non-conflicting rows follow that policy; each conflict requires an explicit base, left, right or exact custom replacement choice. CRLF, CR, LF, BOM characters and final newline choices remain data. No semantic/code merge, automatic conflict repair or patch application is claimed.
Review and complete downloads
Complete source and run displays use segments of at most 8,192 UTF-16 units; every segment remains available. JSON location diagnostics are labelled previews. Comparison exports use fixed input, results, options-only recipe, typed JSON-notation CSV, escaped inert HTML and original line-patch filenames. A patch requires the line text/code profile. Literal merge uses webut-literal-merge.txt and webut-literal-merge-decisions.json. The decision package contains complete private original sources and choices; download it only when you intend to retain that material.
Bounds and lifetime
Text sources are at most 1 MiB each, JSON sources 25 MiB each and 50 MiB combined; results are at most 4 MiB. Word/code-point profiles hold above 100,000 UTF-16 units. Literal merge admits three 1 MiB sources, 10,000 atoms/rows, 4 MiB merged text and a 32 MiB decision package. Keyed-root reservations can refuse smaller sources; its result/CSV/HTML exports retain the 256 KiB ceiling. The complete request envelope remains limited to 64 MiB and can refuse an otherwise individually admitted source/export combination. Refusal never truncates a complete output.
One original processing window of at most thirty seconds includes capture, native read, producer, separate fresh-source verification and complete Blob readback. Reads use at most ten seconds and producer plus verifier at most twenty seconds within that endpoint. Accepted review persists until edits, Cancel, Clear or workflow retirement; it does not expire while you read. Explicit download links use temporary twenty-second revocation timers and can be renewed for the same current accepted data.
Changes withdraw old publication identities before cleanup. Replacement waits the original read/worker/download closures and global ownership gates. Cancellation can remain closing until the exact worker terminal; uncertainty prevents new work until reload while Clear still discards private inputs. Native drain, physical erasure, exact heap/device capacity and full conformance are not proved.
Other structural formats, patch application, qualified grapheme/bidirectional semantics, native-language, regional, accessibility and device acceptance remain required. These bounded operations do not complete the broader text tools or the WebUT product.