ElephantClock ELEPHANTCLOCK.TECH
ElephantClock Blog · Engineering

How to Read an Emirates ID Card in a Web App

Published 26 October 2026 7 min read Emirates ID

Most UAE business software now runs in the browser. Emirates ID readers do not. Here is the architecture that connects the two reliably, and the mistakes that make it insecure.

Why the browser cannot read the card

The Emirates ID is a smart card with a secure chip. Reading it needs low-level access to a PC/SC or NFC reader and the vendor toolkit that handles the card's security protocol. Browsers deliberately expose none of this to web pages. Older approaches relied on Java applets or browser plugins, and those are gone.

That leaves three options: a desktop application that types data into forms, a browser extension, or a local bridge. The first breaks whenever the form changes. The second needs installing and maintaining on every browser. The third is the one that scales.

The local-bridge pattern

A small service runs on the counter PC. It watches the reader, reads the card when it is inserted or tapped, and publishes the result on a local HTTP endpoint. Your web app subscribes to that endpoint and fills the form.

Reader ──► local service (Windows) ──► http://localhost:8080/events ──► your web app

We use Server-Sent Events rather than WebSockets. SSE is a single long-lived HTTP response that every browser supports natively through EventSource, reconnects by itself, and passes through more corporate proxies. Card reads only flow one way, so a two-way socket adds complexity for nothing.

const events = new EventSource('http://localhost:8080/events');
events.onmessage = (m) => {
  const e = JSON.parse(m.data);
  if (e.type === 'card_read') {
    form.name.value = e.fullNameEnglish;
    form.emiratesId.value = e.id;
  }
};

What data you get

An offline read of the card's public data returns the cardholder's name in English and Arabic, ID number, card number, nationality, gender, date of birth, issue and expiry dates, and the photo. Two practical details catch teams out:

  • Dates come as dd/MM/yyyy. Convert them before putting them into <input type="date">.
  • Arabic names must be stored and displayed with correct right-to-left handling. Test with real Arabic text, not transliterations.

The security settings that matter

A local service that hands out ID data is an attractive target, and two defaults decide whether it is safe:

  • Bind to localhost. If the service listens on all network interfaces, any device on the office Wi-Fi can read the stream. Listen on 127.0.0.1 unless tablets genuinely need LAN access, and firewall the port when they do.
  • Restrict browser origins. A permissive Access-Control-Allow-Origin: * lets any website the user visits read card data from localhost. Allow only your application's origin.
  • HTTPS apps and Private Network Access. Chrome now asks local services to approve requests from public sites. Answer the preflight with Access-Control-Allow-Private-Network: true for allowed origins only.

Build without hardware

You do not need a reader to start. Our mock bridge speaks the same protocol and sends synthetic cards:

npx @elephantclock/eid-connect-mock
npm install @elephantclock/eid-connect

The examples repository has a form auto-fill, a visitor kiosk and an age check you can run in two minutes.

Work with us

ElephantClock builds and supports Emirates ID integrations for UAE typing centres, clinics, hotels, real-estate offices and visitor desks. Our developer tools are free for personal and educational use, and commercial deployments are licensed with installation and support.