Hidden Word Scanner

Defined checks, traceable findings

Hidden Word Scanner uses the same basic method across its workspaces: accept a bounded input, apply disclosed rules or reviewed data, expose the evidence or working behind the result, and state what the result cannot establish. A language model does not generate answers, write assignments, or decide what a finding means.

The project has four connected modes of work: inspection for documents, text, and code; calculation for logic, binary, physics, and scientific expressions; verification against constraints and known expectations; and learning through guides and synthetic examples. Results are educational and reviewable outputs, not hidden judgments.

Document scanning selectively uses English-language OCR to recognize text in images. It skips text-only pages and small decorative images, while image-only pages and qualifying mixed pages can be checked. OCR can use machine-learning techniques and can misread text, so this is not a claim that every component is AI-free or that non-English content is fully covered. Findings can also vary with scanner versions, OCR, rendering tools, and inspection limits; compare the recorded versions and coverage when reviewing results.

Check the file, don’t solve the homework. The Python inspector offers cleanup changes you preview and approve; it does not generate solutions or automatically rename variables. Students and educators can use findings to support a human review. Whether outside inspection tools are permitted depends on the course or institution’s policy.

Logic and calculator methodology

Logic Tools use purpose-built parsers and deterministic evaluators rather than JavaScript expression execution. Truth tables enumerate bounded input assignments; equation generation verifies candidate expressions against every edited row; Karnaugh-map groups are checked against the same table. Binary operations use explicit bit widths and signed or unsigned interpretation so exact values, stored values, overflow, and discarded bits can be distinguished.

The calculators accept only supported quantities, formulas, units, operators, and functions. Unit conversion passes through defined canonical units. Formula Lab uses a reviewed catalog of relationships, constraints, assumptions, rearrangements, and unit rules, then displays conversions and substitution steps. The scientific calculator parses an allowlisted expression grammar and applies documented precedence, angle mode, domains, and input limits.

A displayed calculation means the defined evaluator produced that output for the entered values. It does not prove that the user chose the correct model, formula, units, precision, bit interpretation, or method for an assignment or real-world decision. Inputs and results remain in the browser; content-free aggregate completion signals may be sent as described under privacy.

Code inspection methodology

Inspect Code analyzes Python source in the browser without running the submitted program. It checks supported invisible-character and formatting patterns, uses the packaged Python runtime to compile the original and reviewed copies, and performs bounded unresolved-name analysis. Offered cleanup edits remain separate until the user reviews and applies them.

Compilation can identify supported syntax problems, and name analysis can identify supported unresolved references. Neither proves correct behavior, security, originality, style quality, or compliance with an assignment. The inspector does not execute tests, import the submitted program, contact its dependencies, or generate a solution.

Sample Lab methodology

The Sample Lab uses synthetic, non-personal files created to demonstrate specific document structures and findings. Each released sample has reviewed source expectations and a recorded observation from a named scanner version. The catalog matches expected category and location evidence against observed findings and flags missing expectations for review; it does not silently turn a mismatch into a pass.

Four layers remain separate: what exists in the source file, what the scanner reported, what a scanner-generated reference renders, and what a person concludes. Samples teach detector behavior and interpretation; they do not establish performance on every real document or prove intent, authorship, misconduct, or safety.

How to interpret a report

Findings identify evidence for review. They do not prove malicious intent. Confidence describes how closely document evidence matches a detector; it is not a probability that a document is malicious.

A clean scan does not guarantee that a document is safe.

What is inspected

Word

Visible and hidden runs and styles, formatting contrast and size, comments and revisions, headers and footers, notes, text boxes, shape alternate text, core and custom properties, relationships, links, and embedded objects.

Excel

Sheet visibility, hidden rows and columns, cell formatting, comments, formulas and keywords, defined names, links and external relationships, drawings, protection, and embedded objects.

PDF

Text rendering modes, opacity, color and vector backgrounds, size and position, overlapping spans, OCR comparison, annotations, links, attachments, metadata, and JavaScript markers.

PDF finding location states

The visual finding-map scope is PDF page mapping. Word and plain-text findings continue to use textual locations. Excel findings use workbook-, sheet-, row-, column-, range-, or cell-aware textual locations; an optional unannotated workbook reference may be shown separately and never maps findings onto rendered pages.

Exact region: A rectangle supplied directly by validated PDF structure or a detector trace. It uses a solid outline.
Approximate region: A detector-supported surrounding area whose edges are not the exact hidden item. It uses a dashed pattern as well as a text label.
Page-only location: The one-based PDF page is known, but no reliable rectangle exists. The report identifies the page and says that no precise region is available.
Structural/document location: The evidence belongs to metadata, attachments, the document catalog, or another non-page structure. It receives no page marker and no fabricated full-page box.

Coordinates are validated and projected on the server from unrotated crop-box PDF points. Crop offsets and page rotation are taken from the same bounded renderer contract that created the preview. The browser receives normalized positions and does not reconstruct PDF coordinates from finding text.

Plain text document scans

Uploaded text scans check selected Unicode controls, zero-width and bidirectional characters, mixed-script homoglyph risks, readable Base64 or hexadecimal strings, and keyword positions.

Inspect Text workspace

The browser workspace checks characters listed in the versioned Unicode registry, currently zero-width joining and spacing characters plus embedding, override, and isolate controls. It records browser-native UTF-16 offsets and code-point-based line and column positions. Cleanup removes only occurrences the user selects; it does not normalize or otherwise rewrite text.

Python code inspector

Inspect Code checks supported character and formatting patterns, then optionally compiles source and checks unresolved names without executing the program. Original source and the reviewed copy are checked separately. Valid syntax and no reported name issues do not prove correct behavior. Read the Python scanner guide.

Limitations

Password-protected and encrypted content may not be inspectable.
OCR can miss text or misrecognize handwriting, unusual fonts, and low-quality images.
Background matching is strongest for vector PDF backgrounds and may miss complex raster imagery.
Macros and executable behavior are identified structurally but are not executed.
Unsupported formats, corrupted structures, proprietary extensions, remote content, and dynamically loaded content may be omitted.
Homoglyph and encoded-text detection is heuristic and requires context.
Inspect Text reports only characters supported by its displayed registry version. Unlisted unusual characters, visual confusables, grapheme behavior, and normalization differences may remain.
The browser workspace accepts up to 1 MB per inspection. Its Phase 1 release budget is 20 seconds for a one-megabyte inspection on the constrained mobile test profile; typical short text is substantially faster.
Line and column values in Inspect Text count Unicode code points, not user-perceived grapheme clusters.
The scanner never determines intent; a knowledgeable reviewer must verify findings in the source file.
Logic and calculator results are limited to their documented grammars, catalogs, numeric rules, and input bounds; they do not choose the correct model or method for the user.
Static code checks do not observe runtime behavior and cannot prove that a program is correct, secure, original, or complete.
Synthetic samples demonstrate selected known cases and are not a statistical benchmark or a promise of coverage for unrelated files.
Evidence regions explain where detector evidence appears; they are not accusations, redactions, text-selection layers, or proof that content was intentionally concealed.
Rasterization and rounding limit visual precision. Exact controlled regions are tested within the greater of two preview pixels or 0.25% of the corresponding preview dimension.

Evidence packets and responsible interpretation

An evidence packet combines immutable scanner findings with clearly separated student verification choices and optional student notes. It carries the scanner version, methodology version, source-file size and SHA-256 fingerprint, finding precision, preview availability, standard limitations, and a locally calculated packet digest.

The source fingerprint identifies the exact bytes scanned, but it does not establish authorship, origin, possession time, or when the file was received. The packet digest can compare packet copies; it is not a signature, certification, trusted timestamp, or proof that any statement is true.

Exports are assembled in the browser. Temporary preview images, preview URLs, and geometry regions are not embedded. A packet states when previews were unavailable or not requested and preserves textual precision such as exact, approximate, page-only, or document-only.

How to discuss an evidence packet

Preserve the unchanged original file and use the packet as a reference rather than a replacement for the source.
Verify important findings in the application normally used to open the document and describe only what you personally observed.
Consider scanner evidence, student observations, false-positive context, and limitations separately.
When preview or geometry context is missing, request human, accessibility, or technical review instead of guessing.
Follow the institution's published process and ask the responsible instructor or office to clarify policy questions.

Privacy and execution boundary

Logic Tools: mathematical checks

Truth Tables parses one Boolean expression and evaluates every assignment in alphabetical input order, up to eight inputs and 256 rows. It never executes the expression as JavaScript. NOT precedes AND, XOR and OR. Input and nesting limits bound the calculation.

Edited tables support up to four inputs with every output specified as 0 or 1. Canonical sum of products includes one complete term per output-1 row. Exact minimization enumerates valid implicants and solves the cover problem, minimizing product terms first and literals second. Equal-cost answers use ASCII-lexicographic ordering of sorted terms. Both expressions must reproduce every edited row in the evaluator before display; this is not a shortest-expression claim across all Boolean notations.

Karnaugh maps for two to four inputs use Gray-code axes. Each displayed group is evaluated against the edited table; their union covers every 1 and no 0. Explanations identify fixed inputs, eliminated inputs and wraparound edges. Don't-cares, gate diagrams, multiple outputs, circuit timing and hazard analysis are not supported.

Binary Calculator uses integer arithmetic and explicit 4-, 8-, 16- or 32-bit storage, with unsigned or two's-complement interpretation. It distinguishes exact arithmetic results, wrapping overflow and shift-bit discard. Number Converter accepts unsigned decimal integers through 4294967295 and displays whole-byte binary/hex plus standard ASCII only for codes 0–127.

Logic Tools inputs and results remain in the browser. Successful truth-table, number-conversion, binary-calculation and equation-generation actions send separate content-free completion signals. The counter stores only activity totals plus UTC daily and hourly aggregate counts; hourly buckets allow the private admin dashboard to calculate “today” in the administrator’s device time zone. It does not store expressions, operands, tables, results or user identifiers. Repeats count separately; delivery is best effort, with no retries or backfill. Tabs, edits, map selections and exports do not count. Site-wide analytics remains excluded from the workspace.

Learn the workflows in Using Logic Tools and Binary, Hex and ASCII Basics.

Document and code workspaces

Documents submitted to the document scanner are uploaded over HTTPS, written only to an isolated temporary workspace, and removed immediately after the scan, including when inspection fails.

Text pasted or selected in the Inspect Text workspace is processed in the browser and is not submitted to the scanning server. Clipboard and download actions use browser APIs. Leaving or refreshing the page discards the inspection session.

The Python Inspect Code workspace also processes source in the browser without uploading or executing it. Syntax and name checks load runtime files from this application. Cleanup changes require your review, and the workspace excludes site-wide analytics.

A completed Python visibility inspection sends a separate content-free usage signal to this site. Only aggregate totals and UTC daily counts are stored by the counter, with no source, filenames, findings, or user identifiers. Delivery is best effort and does not affect inspection results.

Macros, PDF JavaScript, links, embedded files, and embedded objects are identified as data but are never executed or opened. Filenames, keywords, excerpts, and document contents are not written to application logs by default.

No account is required and persistent server-side history is disabled. A signed browser session limits access to its own temporary reports. Reports expire automatically; export anything you need before leaving.

For each supported PDF scan, the server automatically attempts to create one sanitized annotated derivative after textual findings are validated. The uploaded source remains only in the isolated scan workspace until derivative validation finishes, then is deleted on success or failure. The derivative is owner-scoped, expires with the temporary report within 15 minutes, and is deleted immediately with the report.

The report embeds and downloads the same protected derivative bytes. Exact and approximate detector-supported regions may be marked on pages; page-only and document-only findings remain truthful index entries without fabricated rectangles. If generation is disabled, over budget, or fails validation, the complete textual report remains available.

Annotated derivatives are scanner-generated visual references, not unchanged originals. Important evidence must still be verified in the unchanged original document. Legacy raster previews may remain visible only on unexpired reports created before this transition; new scans do not create them.