Redacting Export-Controlled Technical Data (ITAR/EAR) in a PDF
Every other guide on this site treats redaction as a privacy problem: cover a name, a number, an account, and the worst case is identity theft or embarrassment. A PDF containing export-controlled technical data is a different kind of document, governed by a different body of federal law, with a different worst case — and unlike almost everything else here, simply letting the wrong person look at an unredacted screen can itself be the violation, whether or not the file is ever sent anywhere.
This page is not legal advice, and it cannot tell you whether a specific document of yours is controlled. Classification is a fact-specific determination that belongs to your organization's export compliance office or empowered official. What this page can do is walk through the actual regulatory mechanism — quoting the relevant sections of the International Traffic in Arms Regulations (ITAR), 22 CFR Part 120 — so you understand why "the file was never uploaded" is a privacy answer to an export-control question, and where it falls short.
What counts as "technical data" under ITAR
22 CFR 120.33 defines technical data as information — other than software covered elsewhere in the regulation — "required for the design, development, production, manufacture, assembly, operation, repair, testing, maintenance, or modification of defense articles," explicitly including information in the form of blueprints, drawings, photographs, plans, instructions, or documentation. It also reaches classified information tied to items on the U.S. Munitions List, and information covered by an invention secrecy order. The definition carves out general scientific, mathematical, or engineering principles commonly taught in schools, and information already in the public domain.
Read plainly, that definition does not require a document to look like a weapons schematic. An assembly procedure, a test report with tolerances, a repair manual excerpt, or a dimensioned drawing attached to a request for quote can all qualify, as long as the underlying item is a defense article and the information is not already public. A PDF can pass every privacy screen you own — no names, no Social Security numbers, nothing that identifies a person — and still be a controlled document under this definition.
Why "I never uploaded it" misses the actual exposure
22 CFR 120.50(a)(2) defines export to include "releasing or otherwise transferring technical data to a foreign person in the United States (a deemed export)." No shipment, no attachment, no upload is required for that clause to apply — the release itself is the export. 120.50(b) goes further: a release in the United States to a foreign person is deemed to be an export to every country in which that person holds citizenship or permanent residency, regardless of where the data physically travels afterward.
120.56 defines what counts as a "release" broadly enough to catch situations that have nothing to do with sending a file: visual or other inspection by a foreign person that reveals the data, an oral or written exchange of the data, or the use of access information that causes or enables a foreign person to access, view, or possess unencrypted technical data. Showing an unredacted drawing on a shared screen to a foreign-national colleague, letting a foreign-national contractor use your machine, or — the case that matters most for a redaction tool — having the plaintext document pass through a vendor's server, where the vendor's own staff could include foreign persons, can each independently be a release, and therefore potentially an export. None of those require the finished file to ever be emailed, downloaded by someone else, or published. "This tool never uploads your file" answers whether a copy was transmitted to a third party. It does not, by itself, answer whether a release has already occurred.
The encryption exemption — and why it runs out exactly when you need to redact
22 CFR 120.54(a)(5) carves certain handling of technical data out of the definition of export entirely: sending, taking, or storing technical data is not an export if it is (i) unclassified, (ii) secured using end-to-end encryption, (iii) secured using cryptographic modules — hardware or software — compliant with FIPS 140-2 or its successors (or another method providing security strength at least comparable to AES-128), supplemented by NIST-aligned key management, (iv) not intentionally sent to or stored in a country listed in 22 CFR 126.1, and (v) not sent from such a country. Many export compliance programs lean on this carve-out to justify moving controlled files through ordinary cloud infrastructure, on the reasoning that data encrypted in transit and at rest never triggers a release.
Here is the catch, and it is directly relevant to redaction specifically: that exemption protects data that stays encrypted. Redacting a document requires reading it — locating the exact sentence, dimension, or image that has to be covered — which means the plaintext has to exist somewhere, even momentarily, for a person or a program to find what to black out. If that "somewhere" is a vendor's server, the file is, for that moment, outside the 120.54(a)(5) safe harbor, and whoever operates that server — including support staff, infrastructure engineers, or any automated pipeline with human oversight — becomes someone who could potentially view, access, or possess the unencrypted technical data under 120.56(a)(3). This is the mechanical reason processing location matters more for controlled technical data than it does for most of the personal information this site otherwise discusses: the question is not only whether a breach or a retention policy exposes the file later, but whether a release event under export-control law has already occurred the instant the file was decrypted on infrastructure you do not control.
Processing a PDF entirely in the browser changes exactly that one step. HidePDF reads the bytes from your own disk into the tab's memory, finds and boxes the sensitive regions there, and writes the result back out as a local download; the script makes no network requests of any kind and uses no server-side storage, so the decryption-for-editing moment never happens anywhere but the device you already control. That removes one specific, mechanical exposure. It does not, on its own, make anything ITAR-compliant.
What local processing does not solve
Browser-only processing closes off a vendor's server as a point of exposure. Everything below that is still on you.
- Whether the data is controlled at all. Classification — ITAR technical data, EAR-controlled, or neither — is a determination for your empowered official, not a word search or a public web page.
- Who is physically present while you work. Drawing boxes on an unredacted drawing while a foreign national looks over your shoulder, joins a screen share, or has access to the unlocked device is a release under 120.56(a)(1)–(2), browser-local or not.
- Where the device itself is. 120.54(a)(5)(iv)–(v) still conditions the encryption exemption on avoiding proscribed-country handling even for data that stays encrypted; a device carried into or operating from a restricted location raises questions local processing does not touch.
- Where the files end up afterward. A local tool puts the redacted export in your Downloads folder, not a vetted, access-logged document management system. If your organization requires controlled technical data to live only in an approved repository, you still have to move it there yourself — and keep the unredacted original somewhere equally controlled.
- Ordinary redaction hygiene. Everything this site covers about local redaction generally still applies: the box has to be burned into the page image rather than left as a removable overlay, document metadata does not clean itself, and you still have to verify the export before it goes anywhere.
Common mistakes and misconceptions
Treating "no upload" as a finished compliance answer. It addresses one exposure — a plaintext copy reaching a vendor's server — out of a much longer list that includes classification, physical access, device location, and downstream storage.
Assuming a document has to look sensitive to be controlled. 120.33 reaches ordinary-looking blueprints, drawings, photographs, plans, and instructions whenever they are required for a defense article's design, production, assembly, repair, testing, or maintenance and are not already public.
Assuming a PDF password satisfies the encryption exemption. 120.54(a)(5) and (b) describe a validated cryptographic module meeting FIPS 140-2 or comparable strength with NIST-aligned key management — a higher bar than many compliance teams consider an ordinary PDF viewer's built-in password protection to clear. Treat this as a question for your empowered official rather than an assumption in either direction.
Assuming a PII-focused redaction review also catches controlled technical data. They test different things. A document with no identifiable personal information can still contain a dimensioned drawing or an assembly instruction that a privacy checklist was never designed to flag.
Related guides
Explore more ways to redact PDFs privately, or use the redaction tool above:
- Why upload-based PDF redaction is risky
- What to tell your IT or security team about browser-based PDF redaction
Frequently asked questions
What is a 'deemed export' and why would viewing a PDF trigger it?
Under 22 CFR 120.50(a)(2), releasing or transferring technical data to a foreign person inside the United States is itself defined as an export — a 'deemed export' — with no shipment required. 120.50(b) extends that: a release in the U.S. to a foreign person is deemed an export to every country where that person holds citizenship or permanent residency. 120.56 defines 'release' broadly enough to include a foreign person visually inspecting a document, an oral or written exchange of the data, or being given access that lets them view or possess it unencrypted. So a PDF of controlled technical data can trigger an export the moment the wrong person looks at an unredacted screen, regardless of whether the file itself is ever sent, emailed, or uploaded anywhere.
Does using a browser-based tool like HidePDF make a PDF ITAR-compliant?
No, and treat any claim that it does with suspicion. Processing the PDF entirely in your browser means the plaintext document is never decrypted on a vendor's server, which closes off one specific deemed-export exposure. It says nothing about whether the content is controlled technical data in the first place — that classification call belongs to your organization's empowered official — and it does nothing about who is standing near your screen, where your device physically is, or where you store the downloaded redacted file and the retained original afterward. Local processing removes one risk; it does not replace an export compliance program.
Does password-protecting a PDF satisfy ITAR's encryption exemption for technical data?
Treat that as an open question for your compliance office, not a default yes. The relevant carve-out, 22 CFR 120.54(a)(5), excuses sending, taking, or storing technical data from being treated as an export only if it stays unclassified, is secured with end-to-end encryption using a FIPS 140-2 (or successor) validated cryptographic module — or another method providing at least AES-128-equivalent strength with NIST-aligned key management — and avoids proscribed countries. Many compliance teams read 'validated module' as a higher bar than an ordinary PDF viewer's built-in password encryption meets, since using an encryption algorithm is not the same claim as running a validated module. Confirm with your empowered official before relying on password protection alone.
Is redacting personal information in a PDF the same requirement as redacting ITAR technical data?
No — they are different bodies of law testing different things. Redacting personal information is a privacy exercise: does this field identify a person? Redacting ITAR technical data is an export-control exercise: is this information 'required for the design, development, production, manufacture, assembly, operation, repair, testing, maintenance, or modification' of a defense article, per 22 CFR 120.33, and is it not already public domain? A document can pass a thorough PII review — no names, no Social Security numbers, nothing identifiable — and still contain a dimensioned drawing or assembly instruction that is controlled technical data the PII review was never designed to catch.