Requête JSONPath
Dernière mise à jour : 2 octobre 2026
Exécutez une expression JSONPath sur un document JSON et voyez chaque correspondance avec le chemin où elle a été trouvée. La requête s'exécute dans votre navigateur ; le document n'est envoyé nulle part.
Ce que fait le langage de requête
JSONPath est au JSON ce qu'un chemin de dossier est au système de fichiers : une façon compacte de dire quelles valeurs vous voulez. $ est la racine du document, .name entre dans une propriété et […] sélectionne dans un tableau.
- Enfants :
$.store.bicycle.color, ou$['store']['bicycle']['color']quand le nom doit être mis entre guillemets. - Jokers :
$.store.book[*].titleprend le titre de chaque livre ;$.store.*prend chaque valeur de l'objet store. - Descente récursive :
$..pricetrouve unpriceà n'importe quelle profondeur. Puissant, et facile d'en faire trop — voir ci-dessous. - Indices et tranches :
[0],[-1]pour le dernier,[0:2]pour les deux premiers,[0:5:2]avec un pas. - Unions :
[0,2]et['book','bicycle']en sélectionnent plusieurs d'un coup. - Filtres :
[?(@.price < 10)]garde les éléments dont le prix est inférieur à dix, avec== != < <= > >=et des combinaisons par&&et||.
Les filtres testent l'existence, pas la véracité
Un chemin seul dans un filtre demande si la propriété est là. Ainsi [?(@.inStock)] correspond à un élément dont inStock vaut false : la propriété existe — la lecture de la RFC 9535. Quand vous visez la valeur, dites-le : [?(@.inStock == true)]. C'est la surprise la plus fréquente de JSONPath, et c'est une propriété du langage, non de cet outil.
Ce qu'il ne fait délibérément pas
Les fonctions de filtre comme length(), match() et search() ne sont pas implémentées, pas plus que les expressions régulières, les expressions de script entre parenthèses, ou les extensions parent/frères que certaines bibliothèques ajoutent. Une requête qui les utilise est refusée avec un message plutôt que de renvoyer silencieusement un résultat faux : la page déclare ce qu'elle prend en charge, donc une correspondance ici veut dire ce qu'elle dit.
Questions fréquentes
Quelle syntaxe JSONPath est prise en charge ?
La racine $, l'accès aux enfants avec .name ou ['name'], les jokers .* et [*], la descente récursive ..name et ..*, les indices de tableau y compris négatifs, les tranches [start:end:step], les unions comme [0,1] et ['a','b'], et les filtres [?(@.price < 10)] avec les opérateurs == != < <= > >= combinés par && et ||.
Qu'est-ce qui n'est pas pris en charge ?
Les fonctions de filtre comme length(), match() et search(), les expressions régulières, les expressions de script entre parenthèses et les extensions que certaines bibliothèques ajoutent (références au parent et aux frères). Une requête qui les utilise est refusée plutôt que de renvoyer silencieusement un résultat faux.
Pourquoi ?(@.inStock) correspond-il aux éléments dont inStock vaut false ?
Parce qu'un chemin seul dans un filtre teste l'existence, non la véracité : il demande si la propriété est là, et une propriété mise à false est toujours là. Pour tester la valeur, écrivez-le : ?(@.inStock == true). C'est la lecture du filtre selon la RFC 9535.
Chaque correspondance indique-t-elle d'où elle vient ?
Oui. Chaque résultat est listé avec le chemin où il a été trouvé, dans la même notation à points et crochets que celle utilisée pour écrire les requêtes, donc le chemin peut être recollé dans une requête ou dans un autre outil JSON.
Mon document est-il envoyé quelque part ?
Non. Le document est analysé avec JSON.parse dans votre navigateur et la requête s'exécute en mémoire. Rien n'est envoyé et la page continue de fonctionner sans réseau.
Pourquoi $..price a-t-il renvoyé plus que prévu ?
La descente récursive visite chaque niveau du document, donc ..price trouve une propriété price où qu'elle soit — dans les tableaux, les objets imbriqués et les branches sans rapport. Pour restreindre, ancrez la requête avec plus de chemin, par exemple $.store.book[*].price.
Vous préférez vérifier le document avec un schéma ? JSON Schema s'en charge. Une erreur ? Écrivez-nous.