DEV Community: Tanya

How to Remove EXIF and GPS Metadata Before Sharing a Photo

Tanya — Fri, 31 Jul 2026 06:04:44 +0000

A JPEG can contain GPS coordinates, capture times, camera and lens details,
editing software, comments, and copyright fields. That may be useful in a
private archive, but risky in a public issue, marketplace listing, or social
post.

Do not assume the upload destination will remove it. Platforms process formats
differently and can change behavior. Create a clean public copy before the file
leaves your control.

Inspect a sharing copy

Keep the original private. On a separate copy, check for GPS data, timestamps,
camera identifiers, and EXIF, XMP, or IPTC fields. The goal is not to damage
your archive; it is to make a public file containing only what the destination
needs.

A practical workflow is:

Inspect the sharing copy locally.
Export a cleaned file.
Inspect that exact output again.
Review what is visible in the pixels.
Rename it clearly before uploading.

The MonoTools EXIF Inspector & Cleaner does this in the current browser tab.
The selected photo is read through browser APIs and is not uploaded to a
processing server.

Understand the JPEG boundary

JPEG stores metadata in segments around its compressed image data. The cleaner
can remove those segments without recompressing the pixels. It currently
removes APP1 EXIF and XMP, APP2 ICC profiles, APP13 Photoshop and IPTC data,
and JPEG comments when present.

Removing an ICC profile can change color rendering in managed workflows, so
compare the cleaned copy with the original when color accuracy matters.

The cleaned export currently supports JPEG only. PNG and WebP use different
container structures; the tool can inspect them but does not yet rewrite their
metadata.

Check the pixels too

Metadata removal cannot hide information already visible in a photo. Look for
street signs, faces, badges, vehicle plates, screens, shipping labels, QR
codes, landmarks, and reflections. Cropping, blurring, or replacing the image
may still be necessary.

If the public copy also needs resizing or format conversion, do that after the
privacy review, then inspect the final file again. Compression and metadata
cleanup solve different problems.

I maintain MonoTools and wrote a fuller guide for its browser-local EXIF
Inspector & Cleaner:

https://monoware.app/guides/remove-exif-metadata-before-sharing?utm_source=devto&utm_medium=content&utm_campaign=exif_cleanup_guide

Disclosure: MonoTools is my project.

How to Compress Images in the Browser Without Uploading Them

Tanya — Fri, 31 Jul 2026 05:59:23 +0000

A screenshot can be 4000 pixels wide even when a page renders it at 900
pixels. Lowering the quality slider may help, but the better first question is:

What is the largest size at which this image will actually be displayed?

Resize first

If an image never renders wider than 1200 pixels, shipping a 4000-pixel source
wastes download bytes and browser memory. Resize to the largest useful display
width, preserve the aspect ratio, and do not upscale a smaller source.

For a one-off asset, the whole process can stay in the browser:

Decode the selected file locally.
Scale it to a maximum width.
Draw it to a Canvas.
Export with the browser's WebP, JPEG, or PNG encoder.
Compare dimensions and file size, then inspect the preview.

This is how the MonoTools Image Optimizer works. The selected file remains in
the current tab instead of being sent to an image-processing service.

Choose a format for the content

WebP is a useful default for screenshots and mixed-content images. It supports
transparency and often produces smaller files than JPEG or PNG.

JPEG suits photographs when transparency is unnecessary. Reduce quality
carefully around faces, text overlays, sharp UI edges, and gradients.

PNG remains appropriate for lossless graphics and transparency. A browser's
quality setting does not make PNG behave like lossy JPEG, so moving the slider
may have little effect.

Conversion alone is not optimization. Compare the actual output and view it
near its intended page size. Small text, one-pixel borders, shadows, and logo
edges tend to reveal damage first.

Know the limits

Local processing avoids an upload, but decoded images can consume far more
memory than their compressed files. Very large sources may slow the tab or
make Canvas export fail. Reduce the target width or process one image at a
time when that happens.

Browser encoders can also produce slightly different output. This workflow is
good for individual assets and visual review; a versioned build dependency is
better for large batches or reproducible production output.

Use srcset or picture when a page needs several responsive sizes. Also
inspect GPS, camera, or timestamp metadata separately: resizing an image does
not guarantee that private metadata is removed.

I maintain MonoTools and wrote a fuller guide for its browser-local Image
Optimizer:

https://monoware.app/guides/compress-images-locally?utm_source=devto&utm_medium=content&utm_campaign=local_image_compression

Disclosure: MonoTools is my project.

How to Inspect a JWT Without Uploading a Production Token

Tanya — Thu, 30 Jul 2026 16:08:15 +0000

A JSON Web Token often looks like opaque security data, but its header and
payload are normally readable Base64URL segments. That makes local inspection
straightforward. It also creates two common mistakes:

Uploading a live bearer token to an unknown server-side decoder.
Treating decoded claims as proof that the token is authentic.

This workflow separates three different jobs:

Inspecting the token structure.
Checking claims such as issuer, audience and expiration.
Verifying that a trusted issuer signed the token.

The first two can be done locally in a browser tab. The third requires the
expected algorithm and trusted key material.

1. Treat the JWT as a credential

A JWT may be readable, but it can still grant access to an API. If it is a
bearer token, anyone who receives the original compact token may be able to use
it until it expires or is revoked.

Before debugging, decide what kind of token you are handling:

A fake or test token is usually safe to paste into examples.
A staging token may still expose internal systems.
A production token should not be copied into public tools, tickets or chat.

If a production token has already crossed an untrusted boundary, redaction is
not enough. Rotate or revoke it and treat the event as a credential exposure.

2. Split the compact token

A typical JWT has three dot-separated segments:

header.payload.signature

The header and payload are Base64URL-encoded JSON. They are not encrypted by
default. That means you can decode the first two segments locally and read the
claims without sending the compact token to a server.

The header usually includes fields such as:

{
  "alg": "RS256",
  "typ": "JWT",
  "kid": "example-key-id"
}

The payload may include registered claims:

{
  "iss": "https://issuer.example",
  "aud": "api.example",
  "sub": "user_123",
  "exp": 1764211200,
  "nbf": 1764207600,
  "iat": 1764207600,
  "scope": "read:profile"
}

Do not paste a real token into an article, issue or support ticket. Use a
synthetic example or share only the claim values needed to explain the failure.

3. Check the claims that commonly fail

Most authentication debugging starts with a small set of fields.

`iss`

The issuer must match the identity provider or token service expected by the
API. A common failure is using a token from the right environment but the wrong
issuer configuration.

`aud`

The audience should identify the API or client that the token was issued for.
If the token was minted for a different API, the claims may look correct while
the request still fails authorization.

`exp`, `nbf` and `iat`

JWT numeric date fields are seconds since the Unix epoch. Many bugs come from
mixing seconds and milliseconds.

Check:

Is exp already in the past?
Is nbf still in the future?
Does iat make sense for the login or refresh event?
Are the server and client clocks skewed?

Custom roles and scopes

Applications often encode permissions in custom claims such as scope,
roles, permissions or tenant-specific fields. These are useful for
debugging, but they are only trustworthy after signature verification.

4. Decoding is not verification

Anyone can construct a JWT-looking string with a header and payload. A decoder
can tell you what the token claims. It cannot tell you whether the token was
signed by the expected issuer.

Verification needs:

The expected algorithm.
The trusted signing secret or public key.
Issuer and audience checks.
Rejection of unexpected algorithms.
Current time validation for exp and nbf.

For HS256 development tokens, the verifier needs the shared secret. For RS256,
ES256 or production identity providers, the backend normally verifies against a
published JWKS or a configured public key.

Do not trust the alg value from the token by itself. Your verification code
should enforce the algorithm that the application expects.

5. Build a share-safe diagnostic

The useful output of JWT debugging is usually not the original token. It is a
small set of facts:

Token structure: 3 JWT segments
Header alg: RS256
Header kid: example-key-id
Issuer: https://issuer.example
Audience: api.example
Subject: user_123
exp: 1764211200 / 2025-11-27T00:00:00Z
nbf: 1764207600 / 2025-11-26T23:00:00Z
Verification error: audience mismatch

Before sharing the diagnostic:

Remove the original compact token.
Remove unrelated cookies or authorization headers.
Scan the remaining text for other credentials.
Include the exact verification error and expected issuer or audience.

That gives the next person enough context to debug without receiving a reusable
credential.

6. A local workflow

My preferred workflow is:

Decode the JWT header and payload locally.
Convert exp, nbf and iat to readable dates.
Compare iss and aud with the API configuration.
Verify the signature in backend code or a local lab with trusted key material.
Redact the original token before opening a ticket or asking for help.

I maintain MonoTools, including a browser-local JWT decoder and the longer
canonical guide for this workflow:

https://monoware.app/guides/inspect-jwt-without-uploading?utm_source=devto&utm_medium=content&utm_campaign=jwt_local_guide

Disclosure: MonoTools is my project. The guide and decoder are useful for local
inspection, but signature verification still belongs in trusted verification
code with the expected key material.