Published September 5, 2026 · 4 min read
A useful bug screenshot preserves the UI state, error text, timestamp, and relevant context. Size it for the actual tracker, remove unrelated personal data, and compare the compressed image at 100% zoom before attaching it.
Scope and decision boundary
The receiving platform's current rule is authoritative. Avoid universal byte targets and do not sacrifice text, damage evidence, or identity-photo detail merely to achieve a dramatic compression percentage.
Start with the tracker's current rule
GitHub, Jira, Linear, and self-hosted trackers can have different attachment caps, accepted formats, and image-preview behavior. Check the exact project and destination before changing the screenshot; do not optimize to a universal 200 KB or quality-80 target.
Preserve the evidence a developer needs
- Capture the complete error, relevant browser chrome or application state, and enough context to identify where the problem occurred.
- Include a timestamp, build or version, environment, reproduction steps, expected result, and actual result in text—not only inside the image.
- Remove unrelated tabs, notifications, tokens, customer data, email addresses, and other secrets before attaching.
- Keep the original screenshot until the issue is resolved.
Crop and resize before changing format
Crop unrelated pixels first. If the capture is much wider than it will be displayed, resize a copy while keeping text legible at 100% zoom. This often saves more bytes with less damage than aggressive compression.
- Keep PNG for UI text, sharp icons, diagrams, transparency, and small color palettes when the file fits.
- Try WebP if the tracker supports it and the result preserves sharp edges.
- Use JPEG for photo-like content or complex gradients when loss is acceptable; inspect ringing and color blur around text.
- Do not repeatedly recompress the same screenshot. Generate every variant from the original.
A reproducible output check
Record the original and output pixels, bytes, format, tool setting, and destination. View the attachment inside the tracker on desktop and mobile, confirm that text can be read, and make sure redaction or cropping did not remove the clue needed to diagnose the issue.
Sources and verification
Primary sources below were reviewed for this revision on September 1, 2026. Requirements, prices, limits, interfaces, and policies can change; open the source again before acting on a high-stakes or time-sensitive task.
- GitHub Docs: Attaching files — Lists GitHub's current image, video, and other attachment-size limits.
- Chrome DevTools Network panel — Provides a reproducible way to inspect what a browser sends when a file is attached.
- MDN: Image file type and format guide — Compares JPEG, PNG, WebP, and AVIF, including transparency and compression tradeoffs.
- Apple: Using HEIF or HEVC media — Explains when Apple devices preserve HEIF and when sharing may convert it to a more compatible format.
Verification checklist
- Read the current upload rule at the destination and leave reasonable byte headroom.
- Compare the output with the original at 100% zoom, especially text and evidence details.
- Keep originals and upload early enough to recover from a rejection.
Where LoveMyFile fits
Use the LoveMyFile image compressor for the bounded task described here. Keep any authoritative source or original when applicable, verify the output, and use the official destination or an approved specialist system when the task exceeds that boundary.
This article provides technical and editorial guidance, not legal, medical, tax, immigration, or compliance advice.