Resolving DataError When Sharing Files

This guide is part of File System Access API Read and Write Workflows, which itself is part of Native Device Integration Patterns.

Sharing files with navigator.share({ files }) fails in two distinct ways, and the fix depends on which one you hit. A TypeError is thrown synchronously when the payload is structurally invalid — a bare Blob with no name, or an empty array. A DataError is thrown when the payload is well-formed but the target platform refuses the content, typically an unsupported MIME type or an oversized file. This guide walks through pre-validating every file payload with navigator.canShare(), constructing proper File objects, enforcing size limits, and re-reading bytes that have gone stale after a service-worker restart.

Feature Detection Gate

File sharing needs navigator.canShare in addition to navigator.share. Detect all three prerequisites — including the secure context — before you spend effort constructing a payload:

export function canShareFiles() {
  return (
    window.isSecureContext === true &&
    typeof navigator.share === 'function' &&
    typeof navigator.canShare === 'function'
  );
}

navigator.canShare shipped later and separately from navigator.share, so a browser can support text sharing but not files. If canShareFiles() is false, skip the file path entirely and route to a download.

Solution Walkthrough

Step 1 — Turn Bytes into a Named File Object

The most common TypeError comes from passing a Blob straight into the files array. A Blob has a type but no name, and several platforms need the filename to label and route the attachment. Wrap the bytes in a File with an explicit name and MIME type. If you are pulling payloads out of storage — for example ArrayBuffers persisted in IndexedDB — reconstruct the File at share time:

export function toShareableFile(bytes, name, type) {
  // bytes: ArrayBuffer | Blob | Uint8Array
  const blob = bytes instanceof Blob ? bytes : new Blob([bytes], { type });
  // Always produce a File — never share a bare Blob.
  return new File([blob], name, { type: type || blob.type || 'application/octet-stream' });
}

Give the file a real extension that matches its MIME type (report.pdf with application/pdf, not report alone). A mismatched or missing extension is a frequent cause of a target app rejecting the file even when canShare passed.

Step 2 — Enforce a Size Ceiling Before Validating

Oversized payloads can surface as a DataError at share() time, or worse, as a silent failure on memory-constrained devices. Check the byte length before you go any further and reject early with a clear reason:

const MAX_SHARE_BYTES = 25 * 1024 * 1024; // conservative cross-platform ceiling

export function withinSizeLimit(files) {
  const total = files.reduce((sum, f) => sum + f.size, 0);
  return total > 0 && total <= MAX_SHARE_BYTES;
}

Platform ceilings vary and are not formally specified — iOS commonly tolerates roughly 10–50 MB per file depending on the target app, and Chromium is similar. A single conservative limit keeps behaviour predictable across devices. For genuinely large media, prefer a link to a hosted file, as covered in handling large file uploads with the File System Access API.

Step 3 — Pre-flight with canShare, Then Share

Now validate the fully-formed payload with navigator.canShare({ files }). This is the check that prevents DataError: if the platform cannot accept these files, canShare returns false and you must not call share(). Route failures to the download fallback:

export async function shareFiles(files, meta = {}) {
  if (!canShareFiles()) return downloadFallback(files);
  if (!withinSizeLimit(files)) return downloadFallback(files);

  const payload = { files, title: meta.title, text: meta.text };

  // canShare is the gate that prevents DataError at share() time.
  if (!navigator.canShare(payload)) {
    return downloadFallback(files);
  }

  try {
    await navigator.share(payload);
    return { status: 'shared' };
  } catch (err) {
    if (err.name === 'AbortError') return { status: 'cancelled' };
    // DataError/NotAllowedError/etc: recover with a download.
    return downloadFallback(files);
  }
}

function downloadFallback(files) {
  const file = files[0];
  const url = URL.createObjectURL(file);
  try {
    const a = document.createElement('a');
    a.href = url;
    a.download = file.name;
    a.click();
  } finally {
    URL.revokeObjectURL(url);
  }
  return { status: 'downloaded' };
}

Note the finally that revokes the object URL — omitting it leaks memory on every fallback. And note that AbortError is treated as a normal cancel, not a failure, so it does not trigger a download the user did not ask for.

Step 4 — Re-read Stale Files After a Worker Restart

If your share flow runs inside or alongside a service worker — for instance, replaying a queued share — a File you captured earlier may be backed by bytes that no longer resolve after the worker is evicted and restarted. Re-materialize the file from durable storage at the moment of sharing rather than holding a long-lived reference:

export async function materializeFromStore(record) {
  // record.bytes is an ArrayBuffer persisted in IndexedDB — always fresh.
  if (!(record.bytes instanceof ArrayBuffer) || record.bytes.byteLength === 0) {
    throw new Error('stale or empty payload; re-fetch before sharing');
  }
  return toShareableFile(record.bytes, record.name, record.type);
}

Storing the raw ArrayBuffer rather than a File or an object URL sidesteps the staleness problem entirely, because you rebuild a valid File on demand.

Failure Modes and Recovery

Browser and Platform Caveat

File sharing via navigator.share({ files }) is supported on Chromium (Android and desktop), Safari on iOS and macOS, and Edge, but the set of accepted MIME types differs by platform and by the specific target app the user picks. navigator.canShare({ files }) is the only reliable way to ask “will this particular payload be accepted here” before invoking, and it must be feature-detected because some browsers expose navigator.share without it. Because the accepted-type list and size ceiling are not standardized, always keep the download fallback wired — it is the guaranteed path when canShare returns false or a DataError slips through on an edge-case target.

FAQ

Related

• File System Access API Read and Write Workflows
• Handling Large File Uploads with the File System Access API
• Storing File Payloads as ArrayBuffer in IndexedDB