Node.js OCR Uploads: A Privacy Gate for GPS Coordinates and Image Metadata
Short answer: inspect image metadata at upload, remove GPS coordinates before the file enters the OCR queue, and keep the original only when a documented clinical workflow needs it. That default turns privacy into a pipeline boundary instead of a promise made after a photo has already spread. I run a one-person SaaS, so I measure infrastructure in revenue per hour. A healthtech upload is not “just a JPEG.” It can carry a timestamp, camera model, orientation, software history, and location. A prescription photo taken near a clinic may reveal more than the text the product was built to read. The decision is simple for most OCR jobs: normalize and sanitize on upload, then process the sanitized derivative asynchronously. On-demand extraction is useful when users repeatedly revisit the same original, but it increases the number of places where private metadata must be understood and controlled. What does image metadata carry, and why does GPS privacy matter? Metadata is data attached to the image container, not pixels painted into the scene. EXIF can include capture time, camera make, lens details, orientation, and GPS latitude and longitude. XMP and IPTC fields can add author, caption, copyright, or workflow history. PNG may carry text chunks and color profiles; a format conversion can preserve some fields and discard others. That variability is the trap. An OCR model can ignore GPS while a thumbnail service, object store preview, or support download keeps it intact. The privacy boundary must cover every derivative, not only the model request. I once treated “we only send the image bytes to OCR” as proof that metadata was irrelevant. It was not. The upload record still had the original filename and an EXIF-bearing object, so a later debugging download could reconstruct where the photo was taken. The mistake was architectural: I had defined the OCR input, but not the data lifecycle. Three words help: discover, decide, destroy. Discover the fields with a parser. Decide which fields have a business purpose. Destroy or quarantine the rest before fan-out. How should a Node.js healthtech pipeline handle image metadata before OCR? Make upload processing an explicit state transition. The API accepts a bounded stream, writes it to a quarantine location, verifies the decoded dimensions and format, extracts a metadata report, and creates a sanitized derivative. Only that derivative gets an OCR job. The original has a separate retention policy and access scope. type MetadataReport = { format: “jpeg” | “png” | “webp”; width: number; height: number; gpsPresent: boolean; fields: string[]; }; type UploadDecision = | { kind: “reject”; reason: string } | { kind: “sanitize”; report: MetadataReport } | { kind: “retain-original”; report: MetadataReport; justification: string }; export function decideForOcr(report: MetadataReport, clinicalNeed: boolean): UploadDecision { if (report.width < 200 || report.height < 200) { return { kind: “reject”, reason: “image is too small for reliable OCR” }; } if (clinicalNeed) { return { kind: “retain-original”, report, justification: “documented clinical workflow requires the source image”, }; } return { kind: “sanitize”, report }; } The code is the policy seam, not a complete decoder. Use a maintained image library to decode and re-encode pixels, and a metadata parser that exposes GPS and textual fields. Do not copy the input bytes into the derivative and call that sanitization; that preserves the very chunks you meant to remove. Record a hash of the source, the derivative, the parser version, and the decision, but do not put raw coordinates in application logs. Keep the queue payload small: an object identifier, tenant scope, and metadata decision. The worker fetches the sanitized object using a short-lived authorization check. This makes retries idempotent and lets a delete request remove the original without leaving a second copy hidden in a job body. Ship weekly. Outsource the undifferentiated parsing and storage primitives to well-tested libraries, but own the retention rule and audit evidence. Should OCR happen at upload or on demand when GPS coordinates are present? Choice Privacy behavior Operational cost Good fit Sanitize and OCR at upload GPS and other fields are removed before fan-out Queue work even if nobody opens the document Intake forms and one-pass claims Sanitize at upload, OCR on demand Derivative is safe; model work waits for a request More latency on first view and cache rules Large archives with occasional searches Preserve original, OCR on demand Maximum fidelity, highest metadata exposure Hardest access, retention, and deletion story A documented workflow needs source evidence For a small healthtech product, I choose the middle row when OCR is expensive or rarely used, and the first row when users expect search immediately. The privacy rule does not change: the on-demand worker still consumes a sanitized derivative, not an untouched upload. The catch is that early sanitization can remove evidence someone genuinely needs, such as capture time used in a chain-of-custody review. It is not suitable when that field is part of the clinical record; retain it in a restricted store with a stated purpose, access audit, and expiry. Stick with a stricter derivative-only design when the product cannot explain why a field is retained. I am not sure a single “strip all metadata” switch is correct for every regulated workflow. Your mileage may vary. The answer should come from a field inventory and a deletion test, not a vendor default. Failure modes that survive a successful OCR demo Orientation is a common one. EXIF orientation may say “rotate 90 degrees,” while the decoded pixels remain unrotated. If the sanitizer drops the tag without applying the transform, text becomes sideways and recognition quality falls. Normalize orientation into pixels before removing the tag. Another failure is a clean primary object with dirty derivatives. I treat this as a fan-out problem, not a thumbnail problem: the upload handler may create a preview immediately, the OCR worker may create a deskewed image later, and a support endpoint may export the “original” after that. If each path chooses its own source, one forgotten branch can reintroduce GPS or an author field even though the first derivative passed inspection. Generate thumbnails, previews, exports, and OCR inputs from the sanitized canonical derivative, pass only its object identifier through the queue, and make the original inaccessible to those workers by policy. Then test each output by reopening it and asserting that GPS, author, and free-text chunks are absent. This is slower to wire once, but it keeps a new feature from quietly becoming a second metadata pipeline. Tiny rule: one canonical derivative. Deletion needs the same discipline. A user request must cover quarantine files, object versions, queue retries, local worker temp files, and backups according to the retention schedule. A database row marked deleted is not proof that bytes disappeared. Watch the pipeline with counters for rejected dimensions, GPS-present uploads, sanitizer failures, derivative creation time, and deletion completion. Alert on a sanitizer failure before enqueueing OCR. A failed privacy gate should stop fan-out and create an actionable record, not silently fall back to the original. References https://developer.mozilla.org/en-US/docs/Web/Media/Formats/Image_types https://www.exif.org/Exif2-2.PDF https://www.w3.org/TR/PNG/ https://www.hhs.gov/hipaa/for-professionals/privacy/index.html