Add screenshots to README

Author: Krishna-Gudavalli

README.md

@@ -1,10 +1,10 @@
-# FileBeam
+# 📡 FileBeam
 
 [![CI](https://github.com/YOUR_USERNAME/YOUR_REPO/actions/workflows/ci.yml/badge.svg)](https://github.com/YOUR_USERNAME/YOUR_REPO/actions/workflows/ci.yml)
 [![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](LICENSE)
 [![Node](https://img.shields.io/badge/node-%3E%3D18-brightgreen)](package.json)
 
-**Direct, device-to-device file transfer — in the browser, no size limit, nothing stored on a server.**
+**⚡ Direct, device-to-device file transfer — in the browser, no size limit, nothing stored on a server.**
 
 Two devices pair with a 6-digit code. Once they're linked, the file streams straight from one browser to the other over WebRTC. No upload-then-download wait, no storage quota, no accounts.
 
@@ -18,7 +18,12 @@ Two devices pair with a 6-digit code. Once they're linked, the file streams stra
                      (file bytes, not the server)
 ```
 
-## Why it's fast and reliable
+<p float="left">
+  <img src="assets/screenshot-pairing-code.png" alt="Pairing code shown on sending device" width="350">
+  <img src="assets/screenshot-transfer.png" alt="File successfully sent" width="350">
+</p>
+
+## ⚡ Why it's fast and reliable
 
 | | |
 |---|---|
@@ -27,7 +32,7 @@ Two devices pair with a 6-digit code. Once they're linked, the file streams stra
 | **Backpressure-aware** | Files send in 64KB chunks and pause automatically when the connection's buffer fills, so nothing overwhelms either device. |
 | **Works across networks** | Same WiFi uses a direct connection. Different networks (e.g. phone on mobile data, laptop on WiFi) fall back to a TURN relay when configured — see below. |
 
-## Quick start
+## 🚀 Quick start
 
 ```bash
 npm install
@@ -36,7 +41,9 @@ npm start
 
 Open `http://localhost:3000` — on two devices on the same network, or two tabs to try it solo.
 
-## Deploying it for real use
+<img src="assets/screenshot-home.png" alt="FileBeam home screen with Send/Receive options" width="700">
+
+## 🌍 Deploying it for real use
 
 Any Node host works. **[Render](https://render.com)** has a genuine free tier and is the easiest starting point:
 
@@ -47,7 +54,7 @@ Any Node host works. **[Render](https://render.com)** has a genuine free tier an
 
 > Free tier note: the service sleeps after 15 minutes idle and takes ~30–60s to wake on the next visit. Fine for occasional transfers; upgrade to a paid instance if you want it always warm.
 
-## Making cross-network transfers reliable (TURN)
+## 🔧 Making cross-network transfers reliable (TURN)
 
 STUN (used by default) only helps two devices *discover* each other — it doesn't relay traffic. If both devices are on the **same network**, that's usually enough. If they're on **different networks**, a certain share of connections will be blocked by NAT/firewalls unless a **TURN server** is configured to relay the (still end-to-end encrypted) traffic.
 
@@ -66,7 +73,7 @@ TURN_CREDENTIAL=your-credential
 
 Without TURN, FileBeam still works well on the same network and many cross-network pairs — it just can't guarantee a connection in every NAT scenario.
 
-## Troubleshooting
+## 🩺 Troubleshooting
 
 **Stuck on "Connecting"** — signaling worked, but the direct WebRTC link never formed. Check, roughly in order of likelihood:
 
@@ -78,12 +85,12 @@ Without TURN, FileBeam still works well on the same network and many cross-netwo
 
 For deeper digging: `chrome://webrtc-internals` shows the live ICE negotiation and exactly where it's failing.
 
-## Notes
+## 📝 Notes
 
 - Pairing codes are single-use and tied to one session — closing the tab invalidates it.
 - Browsers without the File System Access API (Firefox, Safari) buffer incoming files in memory instead of streaming to disk — fine for most files, but very large ones are limited by available RAM.
 - No database, no file storage, no accounts — restarting the server just clears any pending pairing codes.
 
-## License
+## 📄 License
 
 MIT